Added historical documents. Got from http://www21.ocn.ne.jp/~k-west/SSLandTLS/index-e.html

3 files changed, 5843 insertions, 0 deletions

diff --git a/doc/protocol/draft-benaloh-pct-00.txt b/doc/protocol/draft-benaloh-pct-00.txt
new file mode 100644
index 0000000000..9d6dd35110
--- /dev/null
+++ b/doc/protocol/draft-benaloh-pct-00.txt
@@ -0,0 +1,1684 @@
+Internet Draft					    Josh Benaloh
+						    Butler Lampson
+						    Daniel Simon
+						    Terence Spies
+						    Bennet Yee
+						    Microsoft Corp.
+						    October 1995
+
+	    The Private Communication Technology Protocol
+		     <draft-benaloh-pct-00.txt>
+
+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 obsoleted 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).
+
+This Internet-Draft expires 27 March 1996.
+
+
+2. Abstract
+
+This document specifies Version 1 of the Private Communication
+Technology (PCT) protocol, a security protocol that provides privacy
+over the Internet.  Like SSL (see [1]), the protocol is intended to
+prevent eavesdropping on communications in client/server applications,
+with servers always being authenticated and clients being
+authenticated at the server's option.  However, this protocol corrects
+or improves on several weaknesses of SSL.
+
+
+3. Introduction
+
+The Private Communication Technology (PCT) Protocol is designed to
+provide privacy between two communicating applications (a client and a
+server), and to authenticate the server and (optionally) the client.
+PCT assumes a reliable transport protocol (e.g. TCP) for data
+transmission and reception.
+
+The PCT Protocol is application protocol-independent.  A "higher
+level" application protocol (e.g. HTTP, FTP, TELNET, etc.) can layer
+on top of the PCT Protocol transparently.  The PCT Protocol begins
+with a handshake phase that negotiates an encryption algorithm and
+(symmetric) session key as well as authenticating a server to the
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 1]
+Internet Draft              The PCT Protocol               November 1995
+
+
+client (and, optionally, vice versa), based on certified asymmetric
+public keys. Once transmission of application protocol data begins,
+all data is encrypted using the session key negotiated during the
+handshake.
+
+It should be noted that the PCT protocol does not specify any details
+about verification of certificates with respect to certification
+authorities, revocation lists, and so on.  Rather, it is assumed that
+protocol implementations have access to a "black box" which is capable
+of ruling on the validity of received certificates in a manner
+satisfactory to the implementation's user.  Such a ruling may, for
+instance, involve remote consultation with a trusted service, or even
+with the actual user through a text or graphic interface.
+
+In addition to encryption and authentication, the PCT protocol
+verifies the integrity of messages using a hash function-based message
+authentication code (MAC).
+
+The PCT protocol's record format is compatible with that of SSL (see
+[1]).  Servers implementing both protocols can distinguish between PCT
+and SSL clients because the version number field occurs in the same
+position in the first handshake message in both protocols.  In PCT,
+the most significant bit of the protocol version number is set to one.
+
+The PCT protocol differs from SSL chiefly in the design of its
+handshake phase, which differs from SSL's in a number of respects:
+
+- The round and message structures are considerably shorter and
+  simpler: a reconnected session without client authentication
+  requires only one message in each direction, and no other type of
+  connection requires more than two messages in each direction.
+
+- Negotiation for the choice of cryptographic algorithms and formats
+  to use in a session has been extended to cover more protocol
+  characteristics and to allow different characteristics to be
+  negotiated independently.  The PCT client and server negotiate, in
+  addition to a cipher type and server certificate type, a hash
+  function type and a key exchange type.  If client authentication is
+  requested, a client certificate type and signature type are also 
+  negotiated.
+
+- Message authentication has been revamped so that it now uses
+  different keys from the encryption keys.  Thus, message
+  authentication keys may be much longer (and message authentication
+  therefore much more secure) than the encryption keys, which may be
+  weak or even non-existent.  
+
+- A security hole in SSL's client authentication has been repaired;
+  the PCT client's authentication challenge response now depends on
+  the type of cipher negotiated for the session.  SSL's client
+  authentication is independent of the cipher strength used in the
+  session and also of whether the authentication is being performed
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 2]
+Internet Draft              The PCT Protocol               November 1995
+
+
+  for a reconnection of an old session or for a new one.  As a result,
+  a "man-in-the-middle" attacker who has obtained the session key for
+  a session using weak cryptography can use this broken session to
+  authenticate as the client in a session using strong cryptography.
+  If, for example, the server normally restricts certain sensitive
+  functions to high-security sessions, then this security hole allows 
+  intruders to circumvent the restriction.
+
+- A "verify-prelude" field has been added to the handshake phase,
+  with which the client and server can check that the cipher type
+  (and other) negotiations carried out in the clear have not been
+  tampered with.  (SSL version 3 uses a similar mechanism, but its
+  complete version 2 compatibility negates its security function,
+  by allowing adversaries simply to alter version numbers as well
+  as cipher types.)
+
+
+
+4. PCT Record Protocol Specification
+
+4.1 PCT Record Header Format
+
+For compatibility with SSL, the PCT protocol uses the same basic
+record format as SSL.  In PCT, all data sent is encapsulated in a
+record, an object which is composed of a header and some non-zero
+amount of data.  Each record header contains a two- or three-byte
+length code.  If the most significant bit is set in the first byte of
+the record length code then the record has no padding and the total
+header length is two bytes; otherwise the record has padding and the
+total header length is three bytes. The record header is transmitted
+before the data portion of the record.
+
+Note that in the long header case (three bytes total), the second most
+significant bit in the first byte has special meaning.  When zero, the
+record being sent is a data record.  When one, the record being sent
+is a security escape, and the first byte of the record is an
+ESCAPE_TYPE_CODE that indicates the type of escape.  (Currently, the
+two examples of security escapes are the "out-of-band data" escape and
+the "redo handshake" escape.)  In either case, the length code
+describes how much data is in the record as transmitted; this may be
+greater than the amount of data after decryption, particularly if
+padding was used.
+
+The record length code does not include the number of bytes consumed
+by the record header (two or three). For the two-byte header, the
+record length is computed by (using a "C"-like notation):
+
+RECORD_LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1],
+
+where byte[0] represents the first byte received and byte[1] the
+second byte received. When the three-byte header is used, the record
+length is computed as follows (using a "C"-like notation):
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 3]
+Internet Draft              The PCT Protocol               November 1995
+
+
+RECORD_LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
+IS_ESCAPE = (byte[0] & 0x40) != 0;
+PADDING_LENGTH = byte[2];
+
+The record header defines a value called PADDING_LENGTH. The
+PADDING_LENGTH value specifies how many bytes of data were appended
+to the original record by the sender. The padding data is used to
+make the record length a multiple of the block cipher's block size
+when a block cipher is used for encryption.
+
+The sender of a "padded" record appends the padding data to the end of
+its normal data and then encrypts the total amount (which is now a
+multiple of the block cipher's block size).  The actual value of the
+padding data is unimportant, but the encrypted form of it must be
+transmitted for the receiver to decrypt the record properly.  Once the
+total amount being transmitted is known the header can be properly
+constructed with the PADDING value set appropriately.
+
+The receiver of a padded record uses the PADDING_LENGTH value from the
+header when determining the length of the ACTUAL_DATA in the data
+record (see section 4.2).
+
+
+4.2 PCT Record Data Format
+
+The format of the data portion of an encrypted PCT record is slightly
+different from that of SSL.  However, not only is the record header
+format identical in both protocols, but the first handshake message
+sent in each direction is also sent in the clear, and contains a
+version number field in the same location in both protocols.  (In PCT
+protocol handshake messages, the most significant bit of this field is
+1.)  Hence, PCT is still compatible with SSL, in the sense that PCT
+handshake messages can be recognized and distinguished from SSL
+handshake messages by examination of the version number.
+
+The PCT record is composed of two fields (transmitted and received in
+the order shown):
+
+ENCRYPTED_DATA[N+PADDING_LENGTH]
+MAC_DATA[MAC_LENGTH]
+
+The ENCRYPTED_DATA field contains an encryption of the concatenation
+of ACTUAL_DATA (the N bytes of actual data being transmitted) and
+PADDING_DATA (the use of which is explained below).  The MAC_DATA
+field contains the "Message Authentication Code" (MAC).
+
+PCT handshake records are sent in the clear, and no MAC is used.
+Consequently PADDING_LENGTH will be zero and MAC_LENGTH will be zero.
+For non-handshake data records, the sender appends a PADDING_DATA
+field containing arbitrary data, so that N + PADDING_LENGTH is the
+appropriate length for the cipher being used to encrypt the data.  (In
+the case where a block cipher is used, PADDING_LENGTH must be the
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 4]
+Internet Draft              The PCT Protocol               November 1995
+
+
+minimum value such that the length of the concatenation of ACTUAL_DATA
+and PADDING_DATA is an exact multiple of the cipher's block size.
+Otherwise, PADDING_LENGTH is zero.)
+
+MAC_DATA is computed as follows:
+
+MAC_DATA := Hash( MAC_KEY, Hash( ACTUAL_DATA, PADDING_DATA, 
+SEQUENCE_NUMBER ) )
+
+If the client is sending the record, then the MAC_KEY is the
+CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
+is the SERVER_MAC_KEY.  (The details of the derivation of these keys
+are given in section 5.3.1.)  The selection of the hash function used
+to compute MAC_DATA is discussed in sections 5.2.1 and 5.2.2.  The
+parameters of the inner invocation of the hash function are input into
+the hash function in the order shown above, with SEQUENCE_NUMBER
+represented in network byte order or "big endian" order.  If the
+length of MAC_KEY is not an exact multiple of eight bits, then MAC_KEY
+is considered, for the purposes of MAC computation, to have (fewer
+than eight) zero bits appended to it, to create a string of an
+integral number of bytes for input into the MAC hash function.
+
+The SEQUENCE_NUMBER is a counter which is incremented by both the
+sender and the receiver. For each transmission direction, a pair of
+counters is kept (one by the sender, one by the receiver).  Before the
+first (handshake) record is sent or received in a PCT connection all
+sequence numbers are initialized to zero (except in the case of a
+restarting connection with a token-based exchange type, in which case
+the entire cipher state is preserved; see section 5.2.2).  The
+sender's sender-to-receiver sequence number is incremented after every
+record sent, and the receiver's sender-to-receiver sequence number is
+incremented after every record received.  Sequence numbers are 32-bit
+unsigned quantities, and may not increment past 0xFFFFFFFF.  (See
+section 4.3.2.)
+
+The receiver of a record (whether PCT client or server) first uses the
+sender's WRITE_KEY to decrypt the concatenated ACTUAL_DATA and
+PADDING_DATA fields, then uses the sender's MAC_KEY, the ACTUAL_DATA,
+the PADDING_DATA, and the expected value of the sequence number as
+input into the MAC_DATA function described above (the hash function
+algorithm used is determined the same way for the receiver as for the
+sender).  The computed MAC_DATA must agree bit for bit with the
+transmitted MAC_DATA.  If the two are not identical, then an
+INTEGRITY_CHECK_FAILED error occurs, and it is recommended that the
+record be treated as though it contained no data.  (See section 5.4.)
+The same error occurs if N + PADDING_LENGTH is not correct for the
+block cipher used.
+
+The PCT Record Layer is used for all PCT communications, including
+handshake messages, security escapes and application data transfers.
+The PCT Record Layer is used by both the client and the server at all
+times.
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 5]
+Internet Draft              The PCT Protocol               November 1995
+
+
+For a two-byte header, the maximum record length is 32767 bytes.  For
+a three-byte header, the maximum record length is 16383 bytes.  The
+PCT Handshake Protocol messages are constrained to fit in a single PCT
+Record Protocol record.  Application protocol messages are allowed to
+consume multiple PCT Record Protocol records.
+
+
+4.3 Security Escapes
+
+4.3.1 Out-Of-Band Data
+
+PCT, like SSL, supports the transmission and reception of "out-of-band
+data".  Out of band data is normally defined at the TCP/IP protocol
+level, but because of PCT's privacy enhancements and support for block
+ciphers, this becomes difficult to support.
+
+To send out-of-band data, the sender sends an escape record whose body
+contains a single byte of data which is the ESCAPE_TYPE_CODE value
+PCT_ET_OOB_DATA.  The record following the escape record will be
+interpreted as "out-of-band" data and will only be made available to
+the receiver through an unspecified mechanism that is different from
+the receiver's normal data reception method.  The escape record and
+the transmitted data record are transmitted normally (i.e. encryption,
+MAC computations, and block cipher padding remain in effect).
+
+Note that the escape record and the associated data record are sent
+using normal TCP sending mechanisms, not using the "out of band"
+mechanisms.  Note also that a "Redo Handshake" escape record (see
+below) and its associated handshake messages may be interposed between
+an "Out-of-Band Data" escape record and its associated data record.
+In such a case, the first non-escape, non-handshake record following
+the "Out-of-Band Data" escape record is treated as out-of-band data.
+
+4.3.2  Redo Handshake
+
+PCT allows either the client or the server to request, at any time
+after the handshake phase has been completed for a connection, that
+another handshake phase be performed for that connection.  For
+example, either party is required to request another handshake phase
+rather than allow its sequence number to "wrap" beyond 0xFFFFFFFF.  In
+addition, it is recommended that implementations enforce limits on the
+duration of both connections and sessions, with respect to the total
+number of bytes sent, the number of records sent, the actual time
+elapsed since the beginning of the connection or session, and, in the
+case of sessions, the number of reconnections made.  These limits
+serve to ensure that keys are not used more or longer than it is safe
+to do so; hence the limits may depend on the type and strength of
+cipher, key exchange and authentication used, and may, at the
+implementer's discretion, include indications from the application as
+to the sensitivity of the data being transmitted or received.
+
+To request a new handshake phase for this connection, the sender
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 6]
+Internet Draft              The PCT Protocol               November 1995
+
+
+(client or server) sends an escape record whose body contains a single
+byte of data which is the ESCAPE_TYPE_CODE value PCT_ET_REDO_CONN.
+The escape record is transmitted normally (i.e.  encryption, MAC
+computations, and block cipher padding remain in effect).
+
+There are several cases to consider to ensure that the message
+pipeline gets flushed and to enable handshake messages to be
+distinguished from data records.  The following rules ensure that the
+first messages in the redone handshake are always immediately preceded
+by a "Redo Handshake" escape message.
+
+If the client initiates the "Redo Handshake", it sends the "Redo
+Handshake" escape message immediately followed by a normal
+CLIENT_HELLO message; the server, on receiving the "Redo Handshake"
+escape message, may be in one of two states.  If the last message it
+sent was a "Redo Handshake" escape message, then it simply waits for
+the CLIENT_HELLO message; otherwise, it sends a "Redo Handshake"
+escape message in response, and then waits for the CLIENT_HELLO
+message.
+
+If the server initiates the "Redo Handshake", then the server sends
+the "Redo Handshake" escape message and simply waits for a "Redo
+Handshake" escape message in response; this "Redo Handshake" should be
+immediately followed by a normal CLIENT_HELLO message.  The client, on
+receiving the server's "Redo Handshake" escape message, may be in one
+of two states.  If the last two messages it sent were a "Redo 
+Handshake" escape message followed by a CLIENT_HELLO message, then it
+simply waits for a SERVER_HELLO message; otherwise, it sends a "Redo
+Handshake" escape message in response, followed by a CLIENT_HELLO
+message, and then waits for a SERVER_HELLO message.
+
+In all cases, the sender of the "Redo Handshake" escape message
+continues to process incoming messages, but may not send any
+non-handshake messages until the new handshake completes.
+
+The handshake phase that follows the "Redo Handshake" escape message 
+is a normal one in most respects; the client may request the 
+reconnection of an old session or request that a new session be 
+initiated, and the server, on receiving a reconnection request, can 
+accept the reconnection or demand that a new session be initiated 
+instead.  If a new session is being established, then the server must 
+request client authentication if and only if client authentication 
+was requested during the previous session.  Otherwise, client 
+authentication is optional.  Both parties must verify that the 
+specifications negotiated previously in the session (cipher type, key 
+exchange type, certificate type, hash function type, client 
+certificate type, and signature type), as well as any certificates 
+exchanged, are identical to those found in the new handshake phase.  
+A mismatch results in a SPECS_MISMATCH or BAD_CERTIFICATE error (see 
+section 5.4.)  This ensures that the security properties of the 
+communication channel do not change.
+
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 7]
+Internet Draft              The PCT Protocol               November 1995
+
+
+5. PCT Handshake Protocol Specification
+
+5.1 PCT Handshake Protocol Flow
+
+The PCT Handshake Protocol is used to negotiate security enhancements
+to data sent using the PCT Record Protocol.  The security enhancements
+consist of authentication, symmetric encryption, and message
+integrity.  Symmetric encryption is facilitated using a "Key Exchange
+Algorithm".  PCT version 1 supports RSA {TM} -based key exchange (see
+[13]), Diffie-Hellman key exchange, and FORTEZZA token key exchange.
+
+The PCT Handshake Protocol consists of four messages, sent
+respectively by the client, then server, then client, then server, in
+that order.  (Moreover, under certain circumstances, the last two
+messages are omitted.)  The messages are named, in order,
+CLIENT_HELLO, SERVER_HELLO, CLIENT_MASTER_KEY, and SERVER_VERIFY.
+
+The general contents of the messages depend upon two criteria: whether
+the connection being made is a reconnection (a continuation of a
+previous session) or a new session and whether the client is to be
+authenticated.  (The server is always authenticated.)  The first
+criterion is determined by the client and server together; the
+CLIENT_HELLO will have different contents depending on whether a new
+session is being initiated or an old one continued, and the
+SERVER_HELLO message will either confirm a requested continuation of
+an old session, or require that a new session be initiated.  The
+second criterion is determined by the server, whose SERVER_HELLO may
+contain a demand for authentication of the client.  If the server does
+not require client authentication, and the reconnection of an old
+session is requested by the client and accepted by the server, then
+the CLIENT_MASTER_KEY and SERVER_VERIFY messages are unnecessary, and
+are omitted.
+
+The CLIENT_HELLO message contains a random authentication challenge
+to the server and a request for the type and level of cryptography
+and certification to be used for the session.  If the client is
+attempting to continue an old session, then it also supplies that
+session's ID.
+
+In the case of a new session, the SERVER_HELLO message contains a
+certificate and a random connection identifier; this identifier
+doubles as an authentication challenge to the client if the server
+desires client authentication.  The CLIENT_MASTER_KEY message sent by
+the client in response includes the master key for the session (from
+which session keys are derived), encrypted using the public key from
+the server's certificate, as well as a certificate and response to the
+server's authentication challenge, if requested.  To ensure that
+previous unencrypted handshake messages were not tampered with, their
+keyed hash is included with the CLIENT_MASTER_KEY message.  Finally,
+the server sends a SERVER_VERIFY message which includes a response to
+the client's challenge and a random session id for the session.
+
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 8]
+Internet Draft              The PCT Protocol               November 1995
+
+
+If the server accepts the old session id, then the SERVER_HELLO
+message contains a response to the client's challenge, and a random
+connection identifier which again doubles as a random challenge to the
+client, if the server requires client authentication.  If no client
+authentication is requested, the handshake is finished (although an
+authentication of the client is implicit in the MAC included with the
+client's first data message).  Otherwise, the subsequent
+CLIENT_MASTER_KEY message contains the client's response, and the
+SERVER_VERIFY message simply signals to the client to continue.
+
+For a new session, the handshake phase has the following form (items
+in square brackets are included only if client authentication is
+required):
+
+Client					Server
+------					------
+
+CLIENT_HELLO:
+client challenge;
+client's cipher, hash,
+    server-certificate,
+    and key-exchange 
+    specification lists
+
+					SERVER_HELLO:
+					connection id/server challenge;
+					server's cipher, hash,
+					    server-certificate,
+					    and key-exchange
+					    specification choices;
+					server certificate
+					[; server's signature-type
+					    and client-certificate
+					    specification lists]
+
+CLIENT_MASTER_KEY:
+master key, encrypted with
+    server's public key;
+authentication of previous two
+    messages
+[; client's signature-type and
+    client-certificate
+    specification choices;
+client's certificate;
+client's challenge response]
+
+					SERVER_VERIFY:
+					session id;
+					server's challenge response
+
+
+For a reconnection of an old session, the handshake phase has the
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                 [Page 9]
+Internet Draft              The PCT Protocol               November 1995
+
+
+following form (items in square brackets are included if client
+authentication is required):
+
+Client					Server
+------					------
+
+CLIENT_HELLO:
+client challenge;
+session id;
+client's cipher, hash,
+    server-certificate,
+    and key-exchange 
+    specification lists
+
+					SERVER_HELLO:
+					connection id/server challenge;
+					old session's cipher, hash,
+					    server-certificate,
+					    and key-exchange
+					    specification choices;
+					server's challenge response
+					[; server's signature-type
+					    and client-certificate
+					    specification lists]
+
+[CLIENT_MASTER_KEY:
+client's certificate;
+client's challenge response]
+
+
+					[SERVER_VERIFY]
+
+
+Note that the protocol is asymmetric between client and server.  The
+client authenticates the server because only the server can decrypt
+the master key which is encrypted with the server's public key, and
+the server's challenge response depends on knowing that master key.
+The server authenticates the client because the client signs its
+challenge response with its public key.  The reason for the asymmetry
+is that when there is no client authentication there is no client
+public key, so the client must choose the master key and encrypt it
+with the server public key to hide it from everyone except the server.
+
+Usually the client can safely send data on the underlying transport
+immediately following the CLIENT_MASTER_KEY message, without waiting
+for the SERVER_VERIFY; we call this "initial data".  Sending initial
+data is good because it means that PCT adds only one round trip; it is
+not possible to do better without exposing the server to a replay
+attack.  However, it is unwise to send initial data if for some reason
+it is important for the client to be sure of being in contact with the
+correct server before sending any data.
+
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 10]
+Internet Draft              The PCT Protocol               November 1995
+
+
+5.2 PCT Handshake Protocol Messages
+
+The PCT Handshake Protocol messages are sent using the PCT Record
+Protocol and consist of a single byte message type code, followed by
+some data.  The client and server exchange messages as described
+above, sending either one or two messages each.  Once the handshake
+has been completed successfully, the client sends its first actual
+data.
+
+Handshake protocol messages are sent in the clear, with the exception
+of the key-exchange-related fields in the CLIENT_MASTER_KEY message,
+some of which involve (public-key) encryption.
+
+The following notation is used for PCT messages:
+
+char MSG_EXAMPLE
+char FIELD1
+char FIELD2
+char THING_LENGTH_MSB
+char THING_LENGTH_LSB
+char THING_DATA[(MSB << 8)|LSB];
+...
+
+This notation defines the data in the protocol message, including the
+message type code. The order is presented top to bottom, with the
+topmost element being transmitted first.
+
+For the "THING_DATA" entry, the MSB and LSB values are actually
+THING_LENGTH_MSB and THING_LENGTH_LSB (respectively) and define the
+number of bytes of data actually present in the message. For example,
+if THING_LENGTH_MSB were one and THING_LENGTH_LSB were four then the
+THING_DATA array would be exactly 260 bytes long.  This shorthand is
+used below.  Occasionally, a "THING_DATA" field is referred to as
+"THING", with the word "DATA" omitted.
+
+The names of message elements have prefixes that identify the messages
+in which they appear; these prefixes are sometimes omitted in the text
+when the containing messages are obvious.
+
+Length codes are unsigned values, and when the MSB and LSB are
+combined the result is an unsigned value.  Length values are in bytes.
+
+
+5.2.1 CLIENT_HELLO (Sent in the clear)
+
+char CH_MSG_CLIENT_HELLO
+char CH_CLIENT_VERSION_MSB
+char CH_CLIENT_VERSION_LSB
+char CH_PAD
+char CH_SESSION_ID_DATA[32]
+char CH_CHALLENGE_DATA[32]
+char CH_OFFSET_MSB
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 11]
+Internet Draft              The PCT Protocol               November 1995
+
+
+char CH_OFFSET_LSB
+char CH_CIPHER_SPECS_LENGTH_MSB
+char CH_CIPHER_SPECS_LENGTH_LSB
+char CH_HASH_SPECS_LENGTH_MSB
+char CH_HASH_SPECS_LENGTH_LSB
+char CH_CERT_SPECS_LENGTH_MSB
+char CH_CERT_SPECS_LENGTH_LSB
+char CH_EXCH_SPECS_LENGTH_MSB
+char CH_EXCH_SPECS_LENGTH_LSB
+char CH_KEY_ARG_LENGTH_MSB
+char CH_KEY_ARG_LENGTH_LSB
+char CH_CIPHER_SPECS_DATA[(MSB << 8)|LSB]
+char CH_HASH_SPECS_DATA[(MSB << 8)|LSB]
+char CH_CERT_SPECS_DATA[(MSB << 8)|LSB]
+char CH_EXCH_SPECS_DATA[(MSB << 8)|LSB]
+char CH_KEY_ARG_DATA[(MSB << 8)|LSB]
+
+When a client first connects to a server it is required to send the
+CLIENT_HELLO message.  The server is expecting this message from the
+client as its first message. It is an ILLEGAL_MESSAGE error for a
+client to send anything else as its first message.  The CLIENT_HELLO
+message begins with the PCT version number, and two fixed-length
+fields followed by an offset to the variable length data.  The
+CH_OFFSET field contains the number of bytes used by the various
+fields (currently only length fields) that follow the offset field and
+precede the variable-length fields.  For PCT version 1, this offset
+value is always PCT_CH_OFFSET_V1, i.e., ten.  However, inclusion of
+this field will allow future versions to be compatible with version 1,
+even if the number of these fields changes: a version 1 server should
+be able to find all the PCT version 1 fields in a higher-version
+CLIENT_HELLO message.  The CH_PAD field may contain any value.
+
+The CLIENT_HELLO message includes a string of random bytes used as
+challenge data from the client.  Also, if the client finds a session
+identifier in its cache for the server, then that session-identifier
+data is sent.  Otherwise, the special PCT_SESSION_ID_NONE value is
+used.  In either case, the client specifies in CIPHER_SPECS_DATA,
+HASH_SPECS_DATA, CERT_SPECS_DATA, and EXCH_SPECS_DATA its preferred
+choices of symmetric cipher, key lengths, hash function, certificate,
+and asymmetric key exchange algorithm.  However, if a session
+identifier is sent, then these choices are only relevant in the case
+where the server cannot recognize the session identifier, and a new
+session must therefore be initiated.  If the server recognizes the
+session, then these fields are ignored by the server.
+
+The CHALLENGE_DATA field contains 32 bytes of random bits, to be used
+to authenticate the server.  The CHALLENGE_DATA should be
+cryptographically random, in the same sense as the MASTER_KEY (see
+section 5.3.1).
+
+The CIPHER_SPECS_DATA field contains a list of possible symmetric
+ciphers supported by the client, in order of (the client's)
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 12]
+Internet Draft              The PCT Protocol               November 1995
+
+
+preference.  Each element in the list is a four-byte field, of which
+the first two bytes contain a code representing a cipher type, the
+third byte contains the encryption key length in bits (0-255), and the
+fourth byte contains the MAC key length in bits, minus 64 (values
+0-255, representing lengths 64-319; this encoding enforces the
+requirement that the MAC key length be at least 64 bits).  The entire
+list's length in bytes (four times the number of elements) is placed
+in CIPHER_SPECS_LENGTH.
+
+The HASH_SPECS_DATA field contains a list of possible hash functions
+supported by the client, in order of (the client's) preference.  The
+server will choose one of these to be used for computing MACs and
+deriving keys.  Each element in the list is a two-byte field
+containing a code representing a hash function choice.  The entire
+length of the list (twice the number of elements) is placed in
+HASH_SPECS_LENGTH.
+
+The CERT_SPECS_DATA field contains a list of possible certificate
+formats supported by the client, in order of (the client's)
+preference.  Each element in the list is a two-byte field containing a
+code representing a certificate format.  The entire length of the list
+(twice the number of elements) is placed in CERT_SPECS_LENGTH.
+
+The EXCH_SPECS_DATA field contains a list of possible asymmetric key
+exchange algorithms supported by the client, in order of (the
+client's) preference.  Each element in the list is a two-byte field
+containing a code representing a key exchange algorithm type.  The
+entire length of the list (twice the number of elements) is placed in
+EXCH_SPECS_LENGTH.
+
+The KEY_ARG_DATA field contains an initialization vector to be used in
+a reconnected session when the cipher type is a block cipher (any
+cipher type except PCT_CIPHER_RC4, and any key exchange type except
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4).  If a new session is being requested
+(i.e., the value of CH_SESSION_ID_DATA is PCT_SESSION_ID_NONE), then
+KEY_ARG_LENGTH must be zero.
+
+The CLIENT_HELLO message must be the first message sent by the client
+to the server.  After the message is sent the client waits for a
+SERVER_HELLO message.  Any other message returned by the server (other
+than ERROR) generates the PCT_ERR_ILLEGAL_MESSAGE error.
+
+The server, on receiving a CLIENT_HELLO message, checks the version
+number and the offset field to determine where the variable-length
+data fields start.  (The OFFSET value should be at least
+PCT_CH_OFFSET_V1.)  The server then checks whether there is a non-null
+SESSION_ID field, and if so, whether it recognizes the SESSION_ID.  In
+that case, the server responds with a SERVER_HELLO message containing
+a non-zero RESTART_SESSION_OK field, and the appropriate value (see
+below) in the RESPONSE and CONNECTION_ID fields.  Otherwise, it checks
+whether the CIPHER_SPECS, HASH_SPECS, CERT_SPECS and EXCH_SPECS lists
+in the CLIENT_HELLO message each contain at least one type supported
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 13]
+Internet Draft              The PCT Protocol               November 1995
+
+
+by the server.  If so, then the server sends a SERVER_HELLO message to
+the client as described below; otherwise, the server detects a
+SPECS_MISMATCH error.
+
+5.2.2 SERVER_HELLO (Sent in the clear)
+
+char SH_MSG_SERVER_HELLO
+char SH_PAD
+char SH_SERVER_VERSION_MSB
+char SH_SERVER_VERSION_LSB
+char SH_RESTART_SESSION_OK
+char SH_CLIENT_AUTH_REQ
+char SH_CIPHER_SPECS_DATA[4]
+char SH_HASH_SPECS_DATA[2]
+char SH_CERT_SPECS_DATA[2]
+char SH_EXCH_SPECS_DATA[2]
+char SH_CONNECTION_ID_DATA[32]
+char SH_CERTIFICATE_LENGTH_MSB
+char SH_CERTIFICATE_LENGTH_LSB
+char SH_CLIENT_CERT_SPECS_LENGTH_MSB
+char SH_CLIENT_CERT_SPECS_LENGTH_LSB
+char SH_CLIENT_SIG_SPECS_LENGTH_MSB
+char SH_CLIENT_SIG_SPECS_LENGTH_LSB
+char SH_RESPONSE_LENGTH_MSB
+char SH_RESPONSE_LENGTH_LSB
+char SH_CERTIFICATE_DATA[(MSB << 8)|LSB]
+char SH_CLIENT_CERT_SPECS_DATA[(MSB << 8)|LSB]
+char SH_CLIENT_SIG_SPECS_DATA[(MSB << 8)|LSB]
+char SH_RESPONSE_DATA[(MSB << 8)|LSB]
+
+The server sends this message after receiving the client's
+CLIENT_HELLO message.  The PCT version number in SH_SERVER_VERSION is
+always the maximum protocol version that the server supports; the
+remainder of the message and all subsequent messages will conform to
+the format specified by the protocol version corresponding to the
+minimum of the client and server protocol version numbers.  Unless
+there is an error, the server always returns a random value 32 bytes
+in length in the CONNECTION_ID field.  This value doubles as challenge
+data if the server requests client authentication, and should
+therefore be random in the same sense as the challenge data in the
+CLIENT_HELLO message.  The SH_PAD field may contain any value.
+
+There are two cases for RESTART_SESSION_OK.  In the first case, the
+server returns a zero RESTART_SESSION_OK flag because the CLIENT_HELLO
+message did not contain a session id or because the one it contained
+is unrecognized by the server.  In this case, the server must behave
+as follows:
+
+The server selects any choice with which it is compatible, from each
+of the CH_CIPHER_SPECS, CH_HASH_SPECS, CH_CERT_SPECS and CH_EXCH_SPECS
+lists supplied in the CLIENT_HELLO message.  (These values are
+returned to the client in the SH_CIPHER_SPECS_DATA,
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 14]
+Internet Draft              The PCT Protocol               November 1995
+
+
+SH_HASH_SPECS_DATA, SH_CERT_SPECS_DATA, and SH_EXCH_SPECS_DATA fields,
+respectively.)  The certificate of the type specified in
+SH_CERT_SPECS_DATA and SH_EXCH_SPECS_DATA is placed in the
+CERTIFICATE_DATA field.  The SH_RESPONSE_DATA field is empty, and its
+length is zero.
+
+In the second case, the server returns a non-zero RESTART_SESSION_OK
+flag because the CLIENT_HELLO message contained a session-identifier
+known by the server (i.e. in the server's session-identifier cache).
+In this case, the server must behave as follows:
+
+The server omits the CERTIFICATE_DATA field (with CERTIFICATE_LENGTH
+set to zero), and sets the CIPHER_SPECS_DATA, HASH_SPECS_DATA,
+CERT_SPECS_DATA and EXCH_SPECS_DATA values to the values stored along
+with the session identifier.  There are two subcases: (1) If the
+SH_EXCH_SPECS_DATA does not refer to a TOKEN type, then the
+CLIENT_MAC, SERVER_MAC, CLIENT_WRITE, and SERVER_WRITE keys are
+rederived using the MASTER_KEY from the old session, as well as the
+CONNECTION_ID and CH_CHALLENGE values from the SERVER_HELLO and
+CLIENT_HELLO messages, respectively, for this connection.  (2) If the
+SH_EXCH_SPECS_DATA refers to a TOKEN type, then the keys from the
+on-going session are reused.  In order to obtain fresh key material or
+change the sequence number, TOKEN implementations must use the redo
+handshake mechanism (PCT_ET_REDO_CONN security escape).  When this
+mechanism is used with a TOKEN exchange type, the client must send
+PCT_SESSION_ID_NONE in the CH_SESSION_ID_DATA field of the subsequent
+CLIENT_HELLO message.
+
+The RESPONSE_DATA is constructed by computing the function
+
+Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 
+SH_CONNECTION_ID_DATA, CH_SESSION_ID_DATA ) ).
+
+The CH_CHALLENGE_DATA and CH_SESSION_ID_DATA values are found in the
+CLIENT_HELLO message for this connection.  The SH_CONNECTION_ID_DATA
+value is from this SERVER_HELLO message.  The SERVER_MAC_KEY is the
+one rederived for this connection as described in section 5.3.1.  If
+the length of SERVER_MAC_KEY is not an exact multiple of eight bits,
+then SERVER_MAC_KEY is considered, for the purposes of MAC
+computation, to have (fewer than eight) zero bits appended to it, to
+create a string of an integral number of bytes for input into the MAC
+hash function.  The hash function choice used is determined by the
+SH_HASH_SPECS_DATA field in this SERVER_HELLO message.  The values are
+input into the interior invocation of the hash function in the exact
+order specified above, with the string in quotation marks representing
+actual ASCII text.
+
+In both reconnection cases, if the server requires client
+authentication, then the CLIENT_AUTH_REQ field is set to a non-zero
+value.  Also, a list of (client) certificate types acceptable to the
+server, in order of (the server's) preference, is placed in the
+CLIENT_CERT_SPECS_DATA field, and a list of (client's) signature
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 15]
+Internet Draft              The PCT Protocol               November 1995
+
+
+algorithms supported by the server, in order of (the server's)
+preference, is placed in the CLIENT_SIG_SPECS_DATA field.  The
+certificate type values in the list are from the same set of two byte
+codes used for the CERT_SPECS list appearing in the CLIENT_HELLO
+message, and the signature algorithm type codes are also two bytes
+long.  (See section 5.3.4 and 5.3.5 below.)  The lengths of the lists
+in bytes (twice the number of elements) are placed in the
+CLIENT_CERT_SPECS_LENGTH and CLIENT_SIG_SPECS_LENGTH fields.  If no
+client authentication is required, then these length fields, as well
+as the CLIENT_AUTH_REQ field, are set to zero, and the corresponding
+data fields are empty.
+
+When the client receives a SERVER_HELLO message, it checks whether the
+server has accepted a reconnection of an old session or is
+establishing a new session.  If a new session is being initiated, and
+client authentication is requested, then the client checks whether it
+is compatible with any of the certificate and signature types listed
+in the CLIENT_CERT_SPECS and CLIENT_SIG_SPECS lists.  (Note that the
+server can make client authentication optional for the client simply
+by including PCT_CERT_NONE and PCT_SIG_NONE as a "last resort".)  If
+the client can provide a compatible certificate, then it sends a
+CLIENT_MASTER_KEY message as described below; otherwise, it generates
+a SPECS_MISMATCH error.
+
+If the session is an old one, then the client establishes the new
+CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and SERVER_MAC_KEY
+according to the cipher-specific rules described below in section
+5.3.1.  The client then checks the contents of the RESPONSE_DATA field
+in the SERVER_HELLO message for correctness.  If the response matches
+the value calculated by the client (exactly as described above for the
+server), then the handshake is finished, and the client begins sending
+data; otherwise, a SERVER_AUTH_FAILED error occurs.
+
+
+5.2.3 CLIENT_MASTER_KEY (sent in the clear, except for encrypted keys)
+
+char CMK_MSG_CLIENT_MASTER_KEY
+char CMK_PAD
+char CMK_CLIENT_CERT_SPECS_DATA[2]
+char CMK_CLIENT_SIG_SPECS_DATA[2]
+char CMK_CLEAR_KEY_LENGTH_MSB
+char CMK_CLEAR_KEY_LENGTH_LSB
+char CMK_ENCRYPTED_KEY_LENGTH_MSB
+char CMK_ENCRYPTED_KEY_LENGTH_LSB
+char CMK_KEY_ARG_LENGTH_MSB
+char CMK_KEY_ARG_LENGTH_LSB
+char CMK_VERIFY_PRELUDE_LENGTH_MSB
+char CMK_VERIFY_PRELUDE_LENGTH_LSB
+char CMK_CLIENT_CERT_LENGTH_MSB
+char CMK_CLIENT_CERT_LENGTH_LSB
+char CMK_RESPONSE_LENGTH_MSB
+char CMK_RESPONSE_LENGTH_LSB
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 16]
+Internet Draft              The PCT Protocol               November 1995
+
+
+char CMK_CLEAR_KEY_DATA[(MSB << 8)|LSB]
+char CMK_ENCRYPTED_KEY_DATA[(MSB << 8)|LSB]
+char CMK_KEY_ARG_DATA[(MSB << 8)|LSB]
+char CMK_VERIFY_PRELUDE_DATA[(MSB << 8)|LSB]
+char CMK_CLIENT_CERT_DATA[(MSB << 8)|LSB]
+char CMK_RESPONSE_DATA[(MSB << 8)|LSB]
+
+The client sends this message after receiving the SERVER_HELLO message
+from the server if a new session is being started or if client
+authentication has been requested.  If no client authentication has
+been requested in the SERVER_HELLO message and an old session is being
+reconnected (i.e., if the CLIENT_AUTH_REQ field is zero and the
+RESTART_SESSION_OK field is nonzero), then the CLIENT_MASTER_KEY
+message is not sent.
+
+For TOKEN exchange types, both client and server (re)set the sequence
+numbers to zero when this message is sent/received.
+
+The contents of the CLEAR_KEY_DATA, ENCRYPTED_KEY_DATA, and
+KEY_ARG_DATA fields depend on the contents of the SH_CIPHER_SPECS_DATA
+and SH_EXCH_SPECS_DATA fields in the preceding SERVER_HELLO message.
+These will be described for each possible choice of these values in
+section 5.3.1 and 5.3.2, along with how the various keys
+(CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY, and
+SERVER_MAC_KEY) are derived in each case.  The CMK_PAD field may
+contain any value.
+
+The CMK_VERIFY_PRELUDE_DATA field contains the value
+
+Hash( CLIENT_MAC_KEY, Hash( "cvp", CLIENT_HELLO, SERVER_HELLO ) ).
+
+If the length of CLIENT_MAC_KEY is not an exact multiple of eight
+bits, then CLIENT_MAC_KEY is considered, for the purposes of MAC
+computation, to have (fewer than eight) zero bits appended to it, to
+create a string of an integral number of bytes for input into the MAC
+hash function.  The hash function used is the one specified in
+SH_HASH_SPECS_DATA.  The parameters are input into the hash function
+in the order presented above, with the strings in quotation marks
+representing ASCII text.  Note that the client need only keep a
+"running hash" of all the values passed in these first two messages as
+they appear, then hash the result using the CLIENT_MAC_KEY when
+generated, to compute the value of VERIFY_PRELUDE.
+
+If SH_CLIENT_AUTH_REQ is zero, then CMK_CLIENT_CERT_SPECS_DATA and
+CMK_CLIENT_SIG_SPECS_DATA are both zero, and the CMK_CLIENT_CERT and
+CMK_RESPONSE_DATA fields are empty.  Otherwise, the CMK_RESPONSE_DATA
+field contains the client's authentication response, and the
+CMK_CLIENT_CERT_SPECS_DATA and CMK_CLIENT_SIG_SPECS_DATA fields
+contain the client's choices from the SH_CLIENT_CERT_SPECS_DATA and
+SH_CLIENT_SIG_SPECS_DATA lists, respectively.  The
+CMK_CLIENT_CERT_DATA field contains the client's certificate, which
+must match the certificate type specified in the
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 17]
+Internet Draft              The PCT Protocol               November 1995
+
+
+CMK_CLIENT_CERT_SPECS_DATA field.  Also, the public key in the
+certificate must be a signature key of the type specified in
+CMK_CLIENT_SIG_SPECS_DATA, which in turn must match one of the types
+in the SH_CLIENT_SIG_SPECS_DATA list.
+
+CMK_RESPONSE_DATA is simply a digital signature, using the private
+signature key associated with the public key in the client's
+certificate, of the value in the CMK_VERIFY_PRELUDE_DATA field.  The
+signature algorithm is determined by the CMK_CLIENT_SIG_SPECS_DATA
+field.  (Note that the signature algorithm may itself require that a
+hash function be applied to the data being signed, apart from the one
+used to compute the value in CMK_VERIFY_PRELUDE_DATA.)
+
+Upon receiving a CLIENT_MASTER_KEY message, the server performs the
+cipher-specific functions described in section 5.3 to establish the
+new CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and
+SERVER_MAC_KEY.  The server then checks the VERIFY_PRELUDE_DATA value,
+the client certificate, and the client response for correctness and
+validity (the latter two only if client authentication had been
+requested).  The checks of the VERIFY_PRELUDE_DATA and RESPONSE_DATA
+are performed by recomputing their correct value, and comparing with
+the values received.  The certificate is verified using whatever
+mechanism has been implemented to validate certificates, and the
+signature in the RESPONSE_DATA field is verified using the
+verification algorithm associated with the signature scheme being
+used.  If all of these values pass their checks, then the server sends
+the SERVER_VERIFY message; otherwise, an error occurs
+(INTEGRITY_CHECK_FAILED, BAD_CERTIFICATE, or CLIENT_AUTH_FAILED,
+respectively).
+
+5.2.4 SERVER_VERIFY (Sent in the clear)
+
+char SV_MSG_SERVER_VERIFY
+char SV_PAD
+char SV_SESSION_ID_DATA[32]
+char SV_RESPONSE_LENGTH_MSB
+char SV_RESPONSE_LENGTH_LSB
+char SV_RESPONSE_DATA[(MSB << 8)|LSB]
+
+The server sends this message upon receiving a valid CLIENT_MASTER_KEY
+message from the client.  The SV_PAD field may contain any value.  If
+an old session is being reconnected, then the RESPONSE_DATA field is
+empty, its length is zero, and the SESSION_ID_DATA field may contain
+any value.  Otherwise, the SV_SESSION_ID_DATA field contains a value
+32 bytes in length, which should be generated randomly (in the same
+sense as the CHALLENGE_DATA field in the CLIENT_HELLO message).  The
+value PCT_SESSION_ID_NONE should not be used as a SV_SESSION_ID_DATA
+value.  The contents of the SV_RESPONSE_DATA field are constructed by
+computing the function
+
+Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 
+SH_CONNECTION_ID_DATA, SV_SESSION_ID_DATA ) ).
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 18]
+Internet Draft              The PCT Protocol               November 1995
+
+
+The CH_CHALLENGE_DATA and SH_CONNECTION_ID_DATA values, the choice of
+hash function used, and the value of SERVER_MAC_KEY are determined by
+the CLIENT_HELLO, SERVER_HELLO, SERVER_HELLO and CLIENT_MASTER_KEY
+messages, respectively, immediately preceding the SERVER_VERIFY
+message.  The values are input into the interior invocation of the
+hash function in the exact order specified above, with the string in
+quotation marks representing actual ASCII text.  If the length of
+SERVER_MAC_KEY is not an exact multiple of eight bits, then
+SERVER_MAC_KEY is considered, for the purposes of MAC computation, to
+have (fewer than eight) zero bits appended to it, to create a string
+of an integral number of bytes for intput into the MAC hash function.
+
+When the client receives this message, it verifies the correctness of
+the response data, by computing the hash value as described above and
+comparing it with the one received.  If it is correct, then the client
+proceeds with the first data record transmission; otherwise, a
+SERVER_AUTH_FAILED error occurs.  An implementation may choose to send
+initial data immediately after the CLIENT_MASTER_KEY message, without
+waiting for the SERVER_VERIFY message to arrive, if verifying the
+server's identity before sending it any data is unimportant.
+
+
+5.3  Algorithm and Certificate Types
+
+5.3.1  Key Exchange Algorithms
+
+PCT version 1 permits the following key exchange types:
+
+PCT_EXCH_RSA_PKCS1
+PCT_EXCH_RSA_PKCS1_TOKEN_DES
+PCT_EXCH_RSA_PKCS1_TOKEN_DES3
+PCT_EXCH_RSA_PKCS1_TOKEN_RC2
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4
+PCT_EXCH_DH_PKCS3
+PCT_EXCH_DH_PKCS3_TOKEN_DES
+PCT_EXCH_DH_PKCS3_TOKEN_DES3
+PCT_EXCH_FORTEZZA_TOKEN
+
+Note that the token-based key exchange types specify cipher as well
+(including, implicitly, the FORTEZZA key exchange type); if one of
+these is chosen, then its choice of cipher overrides whatever choice
+of cipher appears in the SH_CIPHER_SPECS_DATA field of the
+SERVER_HELLO message.
+
+For the PCT_EXCH_RSA_PKCS1 key exchange type, a MASTER_KEY value is
+generated by the client, which should be random in the following
+strong sense: attackers must not be able to predict any of the bits in
+the MASTER_KEY.  It is recommended that the bits used be either truly
+random and uniformly generated (using some random physical process) or
+else generated using a cryptographically secure pseudorandom number
+generator, which was in turn seeded with a truly random and uniformly
+generated seed.  This MASTER_KEY value is encrypted using the server's
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 19]
+Internet Draft              The PCT Protocol               November 1995
+
+
+public encryption key, as obtained from the server's certificate in
+the SH_CERTIFICATE_DATA field of the SERVER_HELLO message.  The
+encryption must follow the RSA PKCS#1 standard format (see [2]), block
+type 2.  This encryption is sent to the server in the
+CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message, and is
+decrypted by the server to obtain the MASTER_KEY.
+
+For the PCT_EXCH_DH_PKCS3 key exchange type, a random private value x
+(generated in the same way as the MASTER_KEY above) and corresponding
+public value y are generated by the client following RSA PKCS#3
+standard format (see [3]). The value y is then sent to the server in
+the CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message.
+The client's private value x, along with the public value y' included
+in the server's certificate in the SH_CERTIFICATE_DATA field of the
+SERVER_HELLO message, is used to generate the MASTER_KEY.  The server
+uses its private value, x', along with the y value sent by the client,
+to obtain the same MASTER_KEY value.
+
+For the various TOKEN key exchange types, all the key material is
+contained in the CMK_ENCRYPTED_KEY_DATA field, but the format of the
+data is defined by the token implementation, or by other future
+documents.
+
+The length of the MASTER_KEY depends on the key exchange type.  For
+the PCT_EXCH_RSA_PKCS1 and PCT_EXCH_DH_PKCS3 exchange types, the
+MASTER_KEY is a 128-bit value.  The CLIENT_WRITE_KEY and
+SERVER_WRITE_KEY are computed as follows:
+
+CLIENT_WRITE_KEY_i = Hash( i, "cw", MASTER_KEY, "cw"^i, 
+SH_CONNECTION_ID_DATA, "cw"^i, SH_CERTIFICATE_DATA,"cw"^i, 
+CH_CHALLENGE_DATA, "cw"^i )
+
+SERVER_WRITE_KEY_i = Hash( i, "svw", MASTER_KEY, "svw"^i, 
+SH_CONNECTION_ID_DATA, "svw"^i, CH_CHALLENGE_DATA, "svw"^i )
+
+The values in quotation marks are treated as (sequences of) ASCII
+characters; "x"^i denotes i copies of the string "x" concatenated
+together.  The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA.  The parameters are input into the hash function
+in the order presented above; the variable i is input as a single-byte
+unsigned integer.  The WRITE_KEYs (i.e., CLIENT_WRITE_KEY and
+SERVER_WRITE_KEY) are obtained by concatenating WRITE_KEY_1 through
+WRITE_KEY_m, where m is the negotiated encryption key length (the
+value in the third byte of the SH_CIPHER_SPECS_DATA field) divided by
+the hash output length, in bits, rounded up to the nearest integer.
+This resulting string is then truncated if necessary (by removing bits
+from the end) to produce a string of the correct length.
+
+The CLIENT_MAC_KEY and SERVER_MAC_KEY are computed as follows:
+
+CLIENT_MAC_KEY_i = Hash( i, MASTER_KEY, "cmac"^i, 
+SH_CONNECTION_ID_DATA, "cmac"^i, SH_CERTIFICATE_DATA, "cmac"^i, 
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 20]
+Internet Draft              The PCT Protocol               November 1995
+
+
+CH_CHALLENGE_DATA, "cmac"^i )
+
+SERVER_MAC_KEY_i = Hash( i, MASTER_KEY, "svmac"^i, 
+SH_CONNECTION_ID_DATA, "svmac"^i, CH_CHALLENGE_DATA, "svmac"^i )
+
+The values in quotation marks are treated as (sequences of) ASCII
+characters; "x"^i denotes i copies of the string "x" concatenated
+together.  The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA.  The parameters are input into the hash function
+in the order presented above; the variable i is input as a single-byte
+unsigned integer.  The MAC_KEYs (ie., CLIENT_MAC_KEY and
+SERVER_MAC_KEY) are obtained by concatenating MAC_KEY_1 through
+MAC_KEY_m, where m is the negotiated MAC key length (64 plus the value
+in the fourth byte of the SH_CIPHER_SPECS_DATA field) divided by the
+hash output length, in bits, rounded up to the nearest integer.  This
+resulting string is then truncated if necessary (by removing bits from
+the end) to produce a string of the correct length.
+
+Note that tokens which are capable of deriving keys using "keyed
+hashes", as described above, are free to use the PCT_EXCH_RSA_PKCS1
+or PCT_EXCH_DH_PKCS3 key exchange type to exchange the MASTER_KEY,
+and then to derive the rest of the keys normally.  The TOKEN key
+exchange types are for tokens that cannot do such keyed-hash key
+derivation, and can only use an exchanged key for bulk encryption
+(of, for example, other keys).  Such tokens can exchange multiple
+keys by using an initially exchanged MASTER_KEY to encrypt other
+keys, as described above.
+
+5.3.2  Cipher Types
+
+PCT version 1 permits the following cipher types to be specified:
+
+PCT_CIPHER_DES
+PCT_CIPHER_IDEA
+PCT_CIPHER_RC2
+PCT_CIPHER_RC4
+PCT_CIPHER_DES_112
+PCT_CIPHER_DES_168
+
+Each of these types is denoted by a two-byte code, and is followed in
+CIPHER_SPECS_DATA fields by two one-byte length specifications, as
+described in section 5.2.1.  An encryption length specification of
+zero associated with any cipher denotes the choice of no encryption; a
+key exchange is performed in such cases solely to share keys for MAC
+computation.  The MAC key length must always be at least 64 bits (see
+section 5.2.1).
+
+The CLEAR_KEY_DATA field is used only when encryption keys of length
+less than the standard length for the specified cipher are used;
+otherwise, the field is empty.  When a key length is specified which
+is less than the standard key length for the specified cipher, then
+keys of the specified length are derived normally as described in
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 21]
+Internet Draft              The PCT Protocol               November 1995
+
+
+section 5.3.1, and then "expanded" to derive standard-length keys.
+The expansion proceeds as follows:
+
+1.  Assign to d the result of dividing the standard key length for 
+the cipher, in bits, by the output length of the hash function, in 
+bits, rounded up to the nearest integer.
+
+2.  Divide CLEAR_KEY_DATA sequentially into d equal subsegments.
+(Note that the length of the CLEAR_KEY_DATA field must therefore be a
+multiple of d bytes, and that no two of its d equal parts, when so
+divided, may be identical.)  Denote these subsegments CLEAR_KEY_DATA_1
+through CLEAR_KEY_DATA_d.
+
+3.  Compute the d hash values
+
+STANDARD_LENGTH_KEY_i := Hash( i, "sl"^i, WRITE_KEY, "sl"^i, 
+CLEAR_KEY_DATA_i ).
+
+The values in quotation marks are treated as (sequences of) ASCII
+characters; "x"^i denotes i copies of the string "x" concatenated
+together.  The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA.  The parameters are input into the hash function
+in the order presented above; the variable i is input as a
+single-byte unsigned integer.  The WRITE_KEY is the encryption key
+(CLIENT_WRITE_KEY or SERVER_WRITE_KEY) being expanded to standard
+length. If the length of the WRITE_KEY is not an exact number of
+bytes, then its final byte is padded with zeroes to increase its
+length to an exact number of bytes.
+
+4.  Concatenate STANDARD_LENGTH_KEY_1 through STANDARD_LENGTH_KEY_d,
+and then truncate as necessary (by removing bits from the end) to
+produce the STANDARD_LENGTH_KEY which is actually used for encryption.
+
+The KEY_ARG_DATA field contains a random eight-byte value to be used
+as an initialization vector (IV) for the first encrypted message when
+a block cipher (any cipher except RC4) is used.  The IV for the first
+block encrypted in any subsequent encrypted message is simply the last
+encrypted block of the previous message.  The KEY_ARG_DATA field is
+empty when cipher type PCT_CIPHER_RC4 (or key exchange type
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4) is used.
+
+PCT_CIPHER_DES denotes DES (see [4]).  Its standard key length is 56
+bits.  PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 denote ciphers in
+which the input is first encrypted under DES with a first key, then
+"decrypted" under DES with a second key, then encrypted under DES with
+a third key.  For PCT_CIPHER_DES_112, the first and third keys are
+identical, and correspond to the initial 56 bits of the 112-bit
+WRITE_KEY.  The second key corresponds to the final 56 bits of the
+WRITE_KEY.  For PCT_CIPHER_DES_168, the three keys are distinct, and
+correspond to the first, second, and third 56-bit subsegments of the
+WRITE_KEY.  All three of these DES-based cipher types have 64-bit data
+blocks and are used with cipher block chaining (CBC).
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 22]
+Internet Draft              The PCT Protocol               November 1995
+
+
+The standard key lengths for PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168
+are 112 bits and 168 bits, respectively.  If a key length less than
+the standard length is specified for one of these ciphers (or for
+PCT_CIPHER_DES), then the WRITE_KEY is expanded to the standard length
+as described above.
+
+Note that before use, each 56-bit DES key must be "adjusted" to add
+eight parity bits to form an eight-byte DES key (see [4]).  Similarly,
+if the specified WRITE_KEY length is less than its corresponding
+standard length, then each WRITE_KEY is expanded to the standard
+length using CLEAR_KEY_DATA as described above, to produce one, two,
+or three keys of 56 bits each, which are then each "adjusted" by
+adding parity bits to form an eight-byte key.
+
+PCT_CIPHER_IDEA denotes the IDEA block cipher (see [5]), with 64-bit
+data blocks and cipher block chaining.  This cipher has a standard key
+length of 128 bits.
+
+PCT_CIPHER_RC2 denotes the RC2 block cipher, with 64-bit blocks and
+cipher block chaining.  Like IDEA, this cipher has a standard key
+length of 128 bits.
+
+PCT_CIPHER_RC4 denotes the RC4 stream cipher.  Like the IDEA and RC2
+block ciphers, this cipher has a standard key length of 128 bits.
+
+5.3.3  Hash Types
+
+PCT version 1 permits the following hash function types to be
+specified:
+
+PCT_HASH_MD5
+PCT_HASH_MD5_TRUNC_64
+PCT_HASH_SHA
+PCT_HASH_SHA_TRUNC_80
+PCT_HASH_DES_DM
+
+PCT_CIPHER_MD5 denotes the MD5 hash function (see [6]), with 128-bit
+output.  PCT_CIPHER_MD5_TRUNC_64 denotes the MD5 hash function, with
+its 128-bit output truncated to 64 bits.  PCT_HASH_SHA denotes the
+Secure Hash Algorithm (see [7]), with 160-bit output.
+PCT_HASH_SHA_TRUNC_80 denotes the Secure Hash Algorithm, with its
+160-bit output truncated to 80 bits.  PCT_HASH_DES_DM denotes the
+DES-based Davies-Meyer hash algorithm (see [8]), with 64-bit output.
+
+
+5.3.4  Certificate Types
+
+PCT version 1 permits the following certificate types to be specified:
+
+PCT_CERT_NONE
+PCT_CERT_X509
+PCT_CERT_PKCS7
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 23]
+Internet Draft              The PCT Protocol               November 1995
+
+
+These types apply equally to the client's and server's certificates.
+PCT_CERT_NONE denotes that no certificate is necessary; this type can
+be included by, say, the server as a choice, thereby making
+authentication optional for the client.  PCT_CERT_X509 denotes a
+CCITT X.509 standard-conformant certificate (see [9]).
+PCT_CERT_PKCS7 denotes an RSA PKCS#7 standard-conformant certificate
+(see [10]).
+
+
+5.3.5  Signature Types
+
+PCT version 1 permits the following signature key types to be
+specified:
+
+PCT_SIG_NONE
+PCT_SIG_RSA_MD5
+PCT_SIG_RSA_SHA
+PCT_SIG_DSA_SHA
+
+PCT_SIG_NONE denotes that no signature is necessary; this type can be
+included by the server as a choice, thereby making authentication
+optional for the client.  PCT_SIG_RSA_MD5 denotes the signature scheme
+consisting of hashing the data to be signed using the MD5 hash
+algorithm, and then performing an RSA private-key signature function
+(the inverse of RSA encryption) on the result.  The signature must
+conform to RSA PKCS#1, block type 1 (see [2]).  PCT_SIG_RSA_SHA
+denotes the same signature scheme with SHA substituted for MD5.
+PCT_SIG_DSA_SHA denotes the signature scheme consisting of hashing the
+data to be signed using the SHA hash algorithm, then computing a
+signature of the resulting value using the Digital Signature Algorithm
+(DSA; see [11]).
+
+
+5.4 Errors
+
+Error handling in the PCT protocol is very simple.  When an error is
+detected during the handshake phase, the detecting party sends a
+message to the other party indicating the error so that both parties
+will know about it, and then closes the connection.  If a party
+detects an error after it has sent its last handshake message, the
+detecting party simply closes the connection without sending an error
+message.  In the second case there are only two possible errors, and
+the party that does not detect the error can distinguish them as
+follows: if the server sees an aborted connection and the most recent
+message it sent the client was a handshake message, then the error was
+SERVER_AUTH_FAILED; otherwise, the error was INTEGRITY_CHECK_FAILED.
+
+Receiving an error message also causes the receiving party to close
+the connection.  Servers and clients should not make any further use
+of any keys, challenges, connection identifiers, or session
+identifiers associated with such an aborted connection.
+
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 24]
+Internet Draft              The PCT Protocol               November 1995
+
+
+It is recommended that implementations perform some kind of alert or
+logging function when errors are generated to facilitate monitoring of
+various types of attack on the system.
+
+
+The message sent in the event of a handshake-phase error has the
+following form:
+
+char MSG_ERROR
+char ERROR_CODE_MSB
+char ERROR_CODE_LSB
+char ERROR_INFO_LENGTH_MSB
+char ERROR_INFO_LENGTH_LSB
+char ERROR_INFO_DATA[(MSB << 8)|LSB]
+
+The ERROR_INFO_LENGTH field is zero except in the case of the
+SPECS_MISMATCH error message, which has a six-byte ERROR_INFO_DATA
+field.
+
+The PCT Handshake Protocol defines the following errors:
+
+PCT_ERR_BAD_CERTIFICATE
+
+This error occurs when the client receives a SERVER_HELLO message in
+which the certificate is invalid, either because one or more of the
+signatures in the certificate is invalid, or because the identity or
+attributes on the certificate are in some way incorrect.
+
+PCT_ERR_CLIENT_AUTH_FAILED
+
+This error occurs when the server receives a CLIENT_MASTER_KEY message
+from the client in which the client's authentication response is
+incorrect.  The certificate may be invalid, the signature may be
+invalid, or the contents of the signed response may be incorrect.
+
+PCT_ERR_ILLEGAL_MESSAGE
+
+This error occurs under a number of circumstances.  For example, it
+occurs when an unrecognized security escape code is received, when an
+unrecognized handshake message is encountered, or when the value of
+CH_OFFSET is to large for its CLIENT_HELLO message.
+
+PCT_ERR_INTEGRITY_CHECK_FAILED
+
+This error occurs when either the client or the server receives a
+message in which the MAC_DATA is incorrect.  It is also recommended
+that the record be treated as if it contained no data, in order to
+ensure that applications do not receive and process invalid data
+before learning that it has failed its integrity check.
+
+This error also occurs when the VERIFY_PRELUDE_DATA value sent by the
+client in the CLIENT_MASTER_KEY message (during the handshake phase)
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 25]
+Internet Draft              The PCT Protocol               November 1995
+
+
+is incorrect.  In this case, an error message is sent.
+
+PCT_ERR_SERVER_AUTH_FAILED
+
+This error occurs when the client receives a SERVER_HELLO or
+SERVER_VERIFY message in which the authentication response is
+incorrect.
+
+PCT_ERR_SPECS_MISMATCH
+
+This error occurs when a server cannot find a cipher, hash function,
+certificate type, or key exchange algorithm it supports in the lists
+supplied by the client in the CLIENT_HELLO message.  It also occurs
+when the client cannot find a certificate or signature type it
+supports in the list supplied by the server in a SERVER_HELLO message
+that requests client authentication.  (Note that the client or server
+can select the "NONE" option as the last resort for any security
+feature it wishes to make optional.  For example, the server can make
+client authentication optional for the client by passing a list of
+certificate and signature types, each list containing the "NONE" type
+as the last entry.)  This error may also occur as a result of a
+mismatch in cipher specifications or client authentication requests
+between the initial specifications and those that resulted from a redo
+handshake sequence.
+
+The error message for this error includes a six-byte informational
+field, defined as follows:
+
+char SPECS_MISMATCH_CIPHER
+char SPECS_MISMATCH_HASH
+char SPECS_MISMATCH_CERT
+char SPECS_MISMATCH_EXCH
+char SPECS_MISMATCH_CLIENT_CERT
+char SPECS_MISMATCH_CLIENT_SIG
+
+Each field is set to a non-zero value if and only if the corresponding
+list resulted in a mismatch.  For example, if and only if the
+SPECS_MISMATCH error message is being sent because server failed to
+find a certificate type it supports in the list supplied by the client
+in the CH_CERT_SPECS_DATA field, then the SPECS_MISMATCH_CERT field in
+the error message would be non-zero.
+
+5.5  Constants
+
+Following is a list of constant values used in the PCT protocol
+version 1.
+
+5.5.1  Message type codes
+
+These codes are each placed in the first byte of the corresponding
+PCT handshake phase message.
+
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 26]
+Internet Draft              The PCT Protocol               November 1995
+
+
+PCT_MSG_CLIENT_HELLO 		:=	0x01
+PCT_MSG_SERVER_HELLO 		:=	0x02
+PCT_MSG_CLIENT_MASTER_KEY 	:=	0x03
+PCT_MSG_SERVER_VERIFY 		:=	0x04
+PCT_MSG_ERROR			:=	0x05
+
+5.5.2  Specification Type Codes
+
+These are codes used to specify types of cipher, key exchange, hash
+function, certificate, and digital signature in the protocol.
+
+PCT_EXCH_RSA_PKCS1		:=	0x0001
+PCT_EXCH_RSA_PKCS1_TOKEN_DES	:=	0x0002
+PCT_EXCH_RSA_PKCS1_TOKEN_DES3	:=	0x0003
+PCT_EXCH_RSA_PKCS1_TOKEN_RC2	:=	0x0004
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4	:=	0x0005
+PCT_EXCH_DH_PKCS3		:=	0x0006
+PCT_EXCH_DH_PKCS3_TOKEN_DES 	:=	0x0007
+PCT_EXCH_DH_PKCS3_TOKEN_DES3 	:=	0x0008
+PCT_EXCH_FORTEZZA_TOKEN		:=	0x0009
+
+PCT_CIPHER_DES 		:=	0x0001
+PCT_CIPHER_IDEA		:=	0x0002
+PCT_CIPHER_RC2 		:=	0x0003
+PCT_CIPHER_RC4 		:=	0x0004
+PCT_CIPHER_DES_112	:=	0x0005
+PCT_CIPHER_DES_168	:=	0x0006
+
+PCT_HASH_MD5 		:=	0x0001
+PCT_HASH_MD5_TRUNC_64 	:=	0x0002
+PCT_HASH_SHA 		:=	0x0003
+PCT_HASH_SHA_TRUNC_80 	:=	0x0004
+PCT_HASH_DES_DM 	:=	0x0005
+
+PCT_CERT_NONE 		:=	0x0000
+PCT_CERT_X509 		:=	0x0001
+PCT_CERT_PKCS7 		:=	0x0002
+
+PCT_SIG_NONE 		:=	0x0000
+PCT_SIG_RSA_MD5 	:=	0x0001
+PCT_SIG_RSA_SHA 	:=	0x0002
+PCT_SIG_DSA_SHA 	:=	0x0003
+
+5.5.3  Error Codes
+
+These codes are used to identify errors, when they occur, in error
+messages.
+
+PCT_ERR_BAD_CERTIFICATE		:=	0x0001
+PCT_ERR_CLIENT_AUTH_FAILED	:=	0x0002
+PCT_ERR_ILLEGAL_MESSAGE		:=	0x0003
+PCT_ERR_INTEGRITY_CHECK_FAILED	:=	0x0004
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 27]
+Internet Draft              The PCT Protocol               November 1995
+
+
+PCT_ERR_SERVER_AUTH_FAILED	:=	0x0005
+PCT_ERR_SPECS_MISMATCH		:=	0x0006
+
+5.5.4  Miscellaneous Codes
+
+These include escape type codes, version numbers, and assorted
+constants associated with the PCT protocol.
+
+PCT_SESSION_ID_NONE		:=	0x00 (32 bytes of zeros)
+
+PCT_ET_OOB_DATA 		:= 	0x01
+PCT_ET_REDO_CONN		:=	0x02
+
+PCT_VERSION_1			:=	0x8001
+
+PCT_CH_OFFSET_V1		:=	0x000A
+
+PCT_MAX_RECORD_LENGTH_2_BYTE_HEADER :=	32767
+PCT_MAX_RECORD_LENGTH_3_BYTE_HEADER :=	16383
+
+
+6. Security Considerations
+
+This entire document is about security.
+
+
+References
+
+[1]  K. Hickman and T. Elgamal.  The SSL Protocol.  Internet-draft,
+June 1995.
+
+[2]  RSA Laboratories, "PKCS #1: RSA Encryption Standard", Version
+1.5, November 1993.
+
+[3]  RSA Laboratories, "PKCS #3: "Diffie-Hellman Key-Agreement
+Standard", Version 1.4, November 1993.
+
+[4]  NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
+Standards, US Department of Commerce, Jan. 1977.
+
+[5]  X. Lai, "On the Design and Security of Block Ciphers", ETH Series
+in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
+
+[6]  R. Rivest, RFC 1321: "The MD5 Message Digest Algorithm", April
+1992.
+
+[7]  NIST FIPS PUB 180-1, "Secure Hash Standard", National Institute
+of Standards and Technology, US Department of Commerce, Apr. 1995.
+
+[8]  ISO/IEC 9797, "Data Cryptographic Techniques--Data Integrity
+Mechanism Using a Cryptographic Check Function Employing a Block
+Cipher Algorithm", 1989.
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 28]
+Internet Draft              The PCT Protocol               November 1995
+
+
+[9]  CCITT. Recommendation X.509: "The Directory - Authentication
+Framework". 1988.
+
+[10]  RSA Laboratories, "PKCS #7: Cryptographc Message Syntax
+Standard", Version 1.5, November 1993.
+
+[11]  NIST FIPS PUB 186, "Digital Signature Standard", National
+Institute of Standards and Technology, US Department of Commerce, May
+1994.
+
+[12]  B. Schneier, "Applied Cryptography: Protocols, Algorithms, and
+Source Code in C", John Wiley & Sons, Inc., 1994.
+
+[13]  R.L. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining
+Digital Signatures and Public Key Cryptosystems" MIT Laboratory for
+Computer Science and Department of Mathematics, S.L. Graham,
+R.L. Rivest ed. Communications of the ACM, February 1978 (Vol 21,
+No. 2) pages 120-126.
+
+Patent Statement
+
+This version of the PCT 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.
+
+See existing RFCs, including RFC 1170, that discuss known public key
+cryptography patents and licensing terms and conditions.
+
+The Internet Society, Internet Architecture Board, Internet
+Engineering Steering Group and the Corporation for National 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 user's own responsibility.
+
+Author's Address
+
+Josh Benaloh/Butler Lampson/Daniel R. Simon/Terence Spies/Bennet Yee
+Microsoft Corp.
+One Microsoft Way
+Redmond WA 98052
+USA
+
+pct@microsoft.com
+
+This Internet-Draft expires 27 March 1996.
+
+
+Benaloh/Lampson/Simon/Spies/Yee                                [Page 29]
+
+
diff --git a/doc/protocol/draft-benaloh-pct-01.txt b/doc/protocol/draft-benaloh-pct-01.txt
new file mode 100644
index 0000000000..f9e61ba096
--- /dev/null
+++ b/doc/protocol/draft-benaloh-pct-01.txt
@@ -0,0 +1,2649 @@
+
+Internet Draft				    Daniel Simon
+						    Microsoft Corp.
+						    April 1996
+
+	    The Private Communication Technology Protocol
+		     <draft-benaloh-pct-01.txt>
+
+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 obsoleted 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).
+
+This Internet-Draft expires 10 October 1996.
+
+
+2. Abstract
+
+This document specifies Version 2 of the Private Communication
+Technology (PCT) protocol, a security protocol that provides privacy
+over the Internet.  The protocol is intended to prevent eavesdropping 
+on connection-based communications in client/server applications, 
+with at least one of the two always being authenticated, and each 
+having the option of requiring authentication of the other.  PCT is 
+somewhat similar to SSL ([1]); however, PCT version 1 corrects
+or improves on several weaknesses of SSL, and version 2 also adds a 
+number of new features.  PCT version 2 is fully compatible with PCT 
+version 1.
+
+
+3. Introduction
+
+The Private Communication Technology (PCT) Protocol is designed to
+provide privacy between two communicating applications (a client and a
+server), and to authenticate at least one of the two (typically the
+server) to the other.  The PCT Protocol is application 
+protocol-independent.  A "higher level" application protocol (e.g. 
+HTTP, FTP, TELNET, etc.) can layer on top of the PCT Protocol 
+transparently.
+
+In the PCT protocol, all data is transmitted in the form of 
+variable-length records, each of which has a record header.  These
+records are used to transmit both PCT protocol messages (including
+handshake, error, and key management messages) and application data
+messages.  Exchanges of records between a client and server are 
+grouped into "connections", which are in turn grouped into "sessions".  
+Every PCT connection belongs to some particular session.
+
+Every PCT protocol connection begins with a handshake phase, during 
+which a sequence of handshake messages (comprising the PCT Handshake 
+Protocol) are exchanged, which negotiate a (symmetric) session key 
+for the connection, as well as performing the requested 
+authentications based on certified asymmetric public (signature or 
+key exchange) keys (or on previously shared private "password" keys).  
+Once transmission of application protocol data messages begins in a 
+connection, all data (including error and key management messages) is 
+encrypted using encryption keys derived from a "master key" exchanged 
+during some handshake phase of the connection's session, as well as 
+from the handshake messages that began the connection.  In addition 
+to encryption and authentication, the PCT protocol verifies the 
+integrity of messages using a hash function-based message 
+authentication code (MAC).
+
+PCT assumes a reliable transport protocol (e.g. TCP) for PCT record 
+transmission and reception during the handshake phase (and 
+afterwards as well in version 1); however, use of datagram records 
+in version 2 makes it possible for individual records to be sent 
+independently (as "datagrams"), with neither order nor eventual 
+delivery guaranteed.  
+
+It should be noted that the PCT protocol does not specify any details
+about verification of identities or certificates with respect to 
+account administrators, certification authorities, revocation lists, 
+and so on.  Rather, it is assumed that protocol implementations have 
+access to a "black box" which is capable of ruling on the validity of 
+received identities and certificates in a manner satisfactory to the 
+implementation's user.  Such a ruling may, for instance, involve 
+remote consultation with a trusted service, or even with the actual 
+user through a text or graphic interface.
+
+The PCT protocol's compatibility with, and differences from, SSL 
+([1]) are outlined in the specification of PCT version 1 ([2]).  
+PCT version 2 is fully compatible with PCT version 1, in that an 
+implementation of version 1 is a valid (though less feature-rich) 
+implementation of version 2.  If either the client or server (or 
+both) identifies itself during the handshake phase as using PCT 
+version 1, then the session conforms to the PCT version 1 
+specification, and features introduced in version 2 are not available.
+PCT version 1 compatibility details are given in section 8.
+
+PCT version 2 is different from PCT version 1 in the following 
+respects:
+
+- PCT version 2 has a revised record format which allows handshake 
+  records, error records and data records, as well as "key management" 
+  and "datagram" records (two new record types) to be explicitly 
+  recognized and distinguished from each other based on header 
+  information.  Record headers can also indicate continuations of 
+  previous records, allowing protocol messages of any type to span 
+  multiple records, just as user data already does in PCT version 1.  
+  Finally, encapsulating user data in a new "data message" format 
+  allows the invocation (using assigned data message types) of 
+  intermediate processing, such as compression/decompression,
+
+- PCT version 2 "datagram" records are independently decryptable, 
+  allowing encrypted data to be sent securely across unreliable 
+  transports, where neither delivery nor correct order are 
+  guaranteed.
+
+- PCT version 2 "key management" records allow encryption and/or
+  message authentication keys to be temporarily changed within a 
+  session, to support the transport of pre-encrypted data.
+
+- PCT version 2 adds a "closing connection" key management message to 
+  ensure that connections aren't prematurely closed by someone 
+  unauthorized to do so.
+
+- PCT version 2 message authentication is altered to include record
+  headers.
+
+- The handshake phase of PCT version 2 allows a wider, more symmetrical
+  variety of authentication options:  either client or server or both 
+  may be authenticated, each by means of either a key exchange or 
+  signature public key and certificate.  
+
+- PCT version 2 allows a new "private" authentication type, in which 
+  authentication is based on a previously shared identity-associated
+  private key, rather than a certified public key.
+
+
+4. PCT Record Protocol Specification
+
+4.1 Notation
+
+The following notation is used in this specification to represent
+data field formats in various protocol messages:
+
+char MSG_EXAMPLE
+char FIELD1
+char FIELD2
+char THING_LENGTH[2]
+char ANOTHER_THING_LENGTH[4]
+char THING_DATA[([0] << 8)|[1]]
+char ANOTHER_THING_DATA[([0]<<24)|([1]<<16)|([2]<<8)|[3]]
+...
+
+The order is presented top to bottom, with the topmost field being 
+transmitted first.  The "FIELD1" and "FIELD2" fields are each one 
+byte long; the "THING_LENGTH" and "ANOTHER_THING_LENGTH" fields have 
+lengths of two and four bytes, respectively, as indicated by the 
+numbers in square brackets following the field labels.  Their bytes 
+are indexed by their offset from the beginning of the field, starting 
+with THING_LENGTH[0] and ANOTHER_THING_LENGTH[0], which are the
+first bytes transmitted in their respective fields.
+
+In the "THING_DATA" and "ANOTHER_THING_DATA" entries, the values in
+square brackets indicate byte offset indices in THING_LENGTH and
+ANOTHER_THING_LENGTH, respectively.  As presented above, the notation 
+refers to combining the bytes of the LENGTH field in order to form an 
+unsigned integer, with the bytes arranged in decreasing order of 
+significance.  This integer defines the number of bytes of data in 
+the corresponding DATA field.  For example, if THING_LENGTH[0] were 
+one and THING_LENGTH[1] were four then the THING_DATA array would be 
+exactly 260 bytes long.  And if the values of the four bytes of 
+ANOTHER_THING_LENGTH were zero, one, two and four, respectively, then 
+ANOTHER_THING_DATA would be exactly 66,052 bytes long.  This 
+shorthand form is used throughout the specification; occasionally, a 
+"THING_DATA" field is referred to as "THING", with the word "DATA" 
+omitted.
+
+Individual bits within a data field are denoted as follows:
+
+LEAST_SIGNIFICANT_BIT       := 0x0001
+NEXT_LEAST_SIG_BIT          := 0x0002
+THIRD_LEAST_SIG_BIT         := 0x0004
+...
+
+These bit identifiers correspond to the least, second-least and 
+third-least significant bits (in that order) in a two-byte data 
+field.  The associated hexadecimal values consist of all zero bits
+except for the identified bit.
+
+Computations involving a hash function (sometimes iterated) are 
+denoted as follows:
+
+COMPUTATION_RESULT_i = Hash( "ASCII string hash input 1"^i, 
+HASH_INPUT_2, HASH_INPUT_3^i, Hash( "ASCII string hash input 4",
+HASH_INPUT_5, i ) )
+
+The values in quotation marks are treated as (sequences of) ASCII
+characters; "x"^i (or VARIABLE^i) denotes i copies of the string 
+"x" (or variable VARIABLE, respectively) concatenated together.  The 
+parameters are input into the hash function in the order presented; 
+the variable i, wherever it appears as an input value, is input as a 
+single-byte unsigned integer.  If any input has a length which is not
+an integral number of bytes, then (fewer than eight) zero bits are
+appended to its last byte to produce an input which is an integral 
+number of bytes.  The value of COMPUTATION_RESULT is obtained by 
+concatenating the COMPUTATION_RESULT_i values in order, for values of 
+i in a specified range.  (If no subscript i is present in the 
+specified formula, then the implied range includes only the value 1.)  
+If the resulting value requires truncation, then the truncation is 
+performed by removing bits from the end to obtain a string of the 
+required length.
+
+In the case of elements of specifically named records or messages, 
+the names of record or message elements have prefixes that identify 
+the messages in which they appear.  These prefixes are sometimes 
+omitted in the text when the containing messages are obvious, or 
+when the same elements have more than one possible prefix.
+
+
+4.2 PCT Record Format
+
+4.2.1 Record header format
+
+A PCT record consists of a four-byte header followed by a 
+variable-length body.  The maximum length of the body is 32763 
+bytes. 
+
+The PCT record header formats differ in versions 1 and 2.  The 
+version 2 record header will be described in this section; its 
+compatibility with the version 1 header (which is described fully 
+in [2]) is explained in section 8.
+
+The PCT version 2 record header has the following structure:
+
+char RH_RECORD_LENGTH[2]
+char RH_RECORD_TYPE[2]
+
+RECORD_LENGTH is an unsigned integer representing the length of the
+(cleartext) data following the length field in the record header
+(including the RH_RECORD_TYPE field and the subsequent record body).
+The first (most significant) bit of the first (most significant) 
+byte of this field is set to one, for backward compatibility reasons
+(see section 9); this bit must be reset to zero to obtain the
+correct unsigned integer value.  Note that if encryption expands the 
+length of the data, the length of the (fully or partially encrypted) 
+record body plus RH_RECORD_TYPE field will not match the value in 
+RECORD_LENGTH; the effect of each cipher on data length is described 
+in section 6.1.5.
+
+RECORD_TYPE is a two-byte field indicating the type of contents in the 
+record, and in particular, how the record should be processed.  PCT 
+version 2 defines a number of record type values for specific record 
+types; other record types are used to identify PCT version 1 (or 
+SSL version 2 or 3) connections, for appropriate processing.  These 
+are RT_VERSION_1_CH, RT_VERSION_1_SH, RT_SSL_VERSION_2_CH, 
+RT_SSL_VERSION_2_SH and RT_SSL_VERSION_3, respectively.  (Note that 
+type RT_SSL_VERSION_3 is defined only on the first, or most 
+significant, byte; the second, or least significant byte can have 
+any value.)  The normal PCT version 2 record types are RT_HANDSHAKE, 
+RT_DATAGRAM, RT_KEY_MGMT, RT_ERROR, and RT_USER_DATA; their 
+associated record data formats are described in section 4.3.  All
+other defined record types are reserved, and must never be used.
+One of them, RT_CD_RESERVED, is also explicitly defined to preclude 
+use in future versions.
+
+
+4.3 PCT Record Body Formats
+
+4.3.1 Handshake Record Body Format
+
+PCT version 2 Handshake records (those with RECORD_TYPE 
+RT_HANDSHAKE) have a very simple body format:
+
+char HS_MSG_TYPE[2]
+char HS_RECORD_FLAGS[2]
+char HS_HANDSHAKE_DATA[RH_RECORD_LENGTH - 6]
+
+The possible HS_MSG_TYPE values are HS_CLIENT_HELLO,
+HS_SERVER_HELLO, HS_CLIENT_MASTER_KEY, HS_SERVER_VERIFY, and
+HS_CLIENT_VERIFY.  HS_RECORD_FLAGS is a two-byte field containing 
+informational flags about the handshake record.  The only two flags 
+defined in PCT version 2 are the last (least significant) two bits 
+of HS_RECORD_FLAGS:
+
+HS_FLAG_TO_BE_CONTD         :=  0x0001
+HS_FLAG_CONTINUATION        :=  0x0002
+
+The last (least significant) bit, HS_FLAG_TO_BE_CONTD, indicates 
+when set that the next record received of the same type is to be 
+considered a continuation of the current one.  The 
+second-least-significant bit, HS_FLAG_CONTINUATION, indicates when 
+set that the record is to be considered a continuation of the 
+previous record received of the same type.  (For PCT version 1 
+compatibility reasons, a CLIENT_HELLO message must not be continued 
+over more than one handshake record.)  The remaining flag bits are 
+reserved, and must be set to zero.  
+
+The HS_HANDSHAKE_DATA field contains data from a PCT handshake 
+message; the structure of these messages is described in section 
+5.2.  Note that a single handshake message may stretch across more 
+than one handshake record; in that case the appropriate flags are set 
+in the record header.  (A restriction on how a handshake message is
+fragmented among records is given in section 5.2.)
+
+4.3.2 Datagram Records
+
+A datagram record is an independently decryptable data record; its
+enclosed data message can be decrypted, and its MAC checked, 
+regardless of whether previous records were delivered in order (or 
+at all).  Datagrams can hence be used if the underlying transport
+does not guarantee in-order delivery of records; for example, it 
+makes possible the transmission of "out-of-band" data for rapid 
+delivery in a TCP connection.
+
+The format of PCT version 2 datagram records is as follows: 
+
+char DG_ENCRYPTED_KEY_LENGTH[2]
+char DG_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
+char DG_ENCRYPTED_DATA[ENCRYPTED_LENGTH]
+char DG_MAC_DATA[MAC_LENGTH]
+
+The DG_ENCRYPTED_KEY_DATA field contains the key information necessary
+to perform decryption and MAC verification of the datagram record; its
+contents are described in section 6.1.3.  The DG_ENCRYPTED_DATA field 
+contains an encryption of ACTUAL_DATA (consisting of the ACTUAL_LENGTH
+bytes of the datagram's enclosed data message).  The DG_MAC_DATA field 
+contains the "Message Authentication Code" (MAC); its contents are 
+described in section 7.3.  Note that ACTUAL_LENGTH can be calculated 
+directly as RECORD_LENGTH - ENCRYPTED_KEY_LENGTH - MAC_LENGTH - 4.  The 
+length of the encrypted datagram record body plus RH_RECORD_TYPE field
+may be greater than RECORD_LENGTH, as a result of expansion during 
+encryption; see section 6.1.5.
+
+
+4.3.3  Other Record Types
+
+The bodies of PCT version 2 key management, error and user data 
+records (those with RECORD_TYPE RT_KEY_MGMT, RT_ERROR and 
+RT_USER_DATA, respectively) contain encrypted data, in the following 
+data format:
+
+char DT_ENCRYPTED_DATA[ENCRYPTED_LENGTH]
+char DT_MAC_DATA[MAC_LENGTH]
+
+The ENCRYPTED_DATA field contains an encryption of ACTUAL_DATA 
+(consisting of the ACTUAL_LENGTH bytes of the enclosed data message). 
+The MAC_DATA field contains the "Message Authentication Code" (MAC);
+its contents are described in section 7.3.  ACTUAL_LENGTH can be 
+calculated directly as RECORD_LENGTH - MAC_LENGTH - 2.
+
+
+4.4 Key Management Messages
+
+Key management messages have the following format:
+
+char KM_KEY_MGMT_TYPE[2]
+char KM_NEW_HASH_TYPE[2]
+char KM_NEW_CIPHER_TYPE[4]
+char KM_WRITE_KEY_LENGTH[2]
+char KM_WRITE_KEY_DATA[([0] << 8)|[1]]
+
+There are four possible values of KM_KEY_MGMT_TYPE:
+KM_TYPE_FIXED_KEY (setting up the transmission of pre-encrypted data), 
+KM_TYPE_RESUME_KEY (used to end transmission of pre-encrypted data), 
+KM_TYPE_REDO_HANDSHAKE (triggering a new run of the handshake 
+protocol), and KM_TYPE_CLOSE_CONN (preceding the closure of a 
+connection).
+
+4.4.1 Preencrypted data
+
+A KM_KEY_MGMT_TYPE value of KM_TYPE_FIXED_KEY indicates that the key 
+management message contains a fixed encryption key with which 
+subsequent data records will be encrypted until further notice.  
+Using this type of key management message, a client or server can 
+send data that has been pre-encrypted and stored in encrypted form.  
+Note that pre-encrypted data can be pre-MAC'd as well.  (See section 
+7.3.)  Note also that a key management message of this type must not 
+be sent unless both client and server have indicated support for the 
+pre-encrypted data feature during the handshake phase associated with 
+this connection; see sections 5.2.1 and 5.2.2.
+
+In a message of type KM_TYPE_FIXED_KEY, KM_NEW_CIPHER_TYPE contains a 
+cipher type code, and KM_NEW_HASH_TYPE contains a hash function type 
+code (see sections 6.2 and 6.3, respectively).  These types must be
+supported by the receiver of this message, as indicated in during the 
+handshake phase for this connection.  (See sections 5.2.1 and 5.2.2.)  
+The fixed encryption key (WRITE_KEY) is sent in the field 
+KM_WRITE_KEY_DATA. 
+
+Note that the encryption and MAC calculation used for the key 
+management message itself, and for subsequent non-data records, are 
+not altered.  However, subsequent data records in the same direction 
+are encrypted using the WRITE_KEY sent in the KM_WRITE_KEY_DATA 
+field, until a key management message of type KM_TYPE_FIXED_KEY or 
+KM_TYPE_RESUME_KEY is sent and received, or until the connection 
+closes.  (Note that pre-encrypted data is not "nested"; a 
+KM_TYPE_FIXED_KEY message is treated as a KM_TYPE_RESUME_KEY message 
+immediately followed by a KM_TYPE_FIXED_KEY message.)  
+
+4.4.2 Restoring original key
+
+A key management message of type KM_TYPE_RESUME_KEY restores the value 
+of the encryption key used for data records transmitted in the same 
+direction to the value originally negotiated during the handshake 
+phase of the current connection.  This key is used until the 
+connection closes, or until a key management message of type 
+KM_TYPE_FIXED_KEY or KM_TYPE_REDO_HANDSHAKE is received.  
+
+In this message, the KM_CIPHER_TYPE and KM_HASH_TYPE messages are set 
+to their original values negotiated during the handshake phase for 
+the current connection.  (See section 5.2.2.)  The remaining data 
+fields are empty, and their length is zero.
+
+
+4.4.3 Closing connection
+
+If both client and server indicated support for the "closing 
+connection" feature during the handshake phase of the current 
+connection (see sections 5.2.1 and 5.2.2), then the connection is 
+"closure-monitored", and closure of a connection is handled in a 
+special way.  Whenever a client or server is about to close a 
+closure-monitored connection without an error, at any point following 
+the completion of the handshake phase of the protocol, an exchange of 
+key management messages of type KM_TYPE_CLOSE_CONN is initiated 
+first.  In both messages, the KM_NEW_CIPHER_TYPE and KM_NEW_HASH_TYPE 
+fields contain the current cipher and hash types, respectively, and 
+the remaining data fields are empty, with length zero.  The sender of 
+one of these messages simply waits for a message of the same type to 
+be received in reply, then closes the connection; a receiver of such 
+a message who has not yet sent one replies with a message of the same 
+type, then closes the connection.  A closure-monitored connection 
+closed without an error before receipt of a message of this type 
+results in a CONN_BROKEN error (see section 4.6).
+
+
+4.4.4  Redo handshake
+
+If both client and server indicated support for the "redo handshake" 
+feature during the handshake phase of the current connection (see 
+sections 5.2.1 and 5.2.2), then the connection is "redo-enabled", and 
+either the client or the server may request, at any time after the 
+handshake phase has been completed for a connection, that another 
+handshake phase be performed for that connection.  For example, 
+either party may request another handshake phase instead of closing 
+the connection in order to avoid allowing a sequence number to "wrap" 
+beyond 0xFFFFFFFF (see section 7.3).  In addition, it is recommended 
+that implementations enforce limits on the duration of both 
+connections and sessions, with respect to the total number of bytes 
+sent, the number of records sent, the actual time elapsed since the 
+beginning of the connection or session, and, in the case of sessions, 
+the number of reconnections made.  These limits serve to ensure that 
+keys are not used more or longer than it is safe to do so; hence the 
+limits may depend on the type and strength of cipher, key exchange and 
+authentication used, and may, at the implementer's discretion, include 
+indications from the application as to the sensitivity of the data 
+being transmitted or received.  They may be enforced using closure of 
+the connection or (in a redo-enabled connection) "redo handshake" key 
+management messages.
+
+To request a new handshake phase for the current connection, the 
+sender (client or server) sends a key management message of type 
+KM_TYPE_REDO_HANDSHAKE.  The KM_NEW_CIPHER_TYPE and KM_NEW_HASH_TYPE
+fields contain the current cipher and hash types, respectively, and
+the remaining data fields are empty, with length zero.
+
+There are several cases to consider to ensure that messages are 
+dealt with in the correct order.  The following rules ensure that the
+first messages in the redone handshake are always immediately preceded
+by a "redo handshake" key management message.
+
+If the client initiates the "redo handshake", it sends the "redo 
+handshake" message immediately followed by a normal CLIENT_HELLO 
+handshake message; the server, on receiving the "redo handshake" 
+message, may be in one of two states.  If the last message it sent 
+was a "redo handshake" message, then it simply waits for the 
+CLIENT_HELLO message; otherwise, it sends a "redo handshake" message 
+in response, and then waits for the CLIENT_HELLO message. 
+
+If the server initiates the "redo handshake", then the server sends 
+the "redo handshake" message and simply waits for a "Redo Handshake" 
+message in response; this "redo handshake" message should be 
+immediately followed by a normal CLIENT_HELLO handshake message. The 
+client, on receiving the server's "redo handshake" message, may be in 
+one of two states.  If the last two messages it sent were a "redo 
+handshake" message followed by a CLIENT_HELLO message, then it simply 
+waits for a SERVER_HELLO handshake message; otherwise, it sends a 
+"redo handshake" message in response, followed by a CLIENT_HELLO 
+message, and then waits for a SERVER_HELLO message.
+
+In all cases, the sender of the "redo handshake" message continues to 
+process incoming messages, but may not send any non-handshake messages 
+until the new handshake completes.  If the connection is 
+closure-monitored (see section 4.4.3), then the sending of an 
+unprovoked "closing connection" key management message between the 
+sending of a "redo handshake" message and the completion of the 
+subsequent handshake is not permitted.  However, in such connections 
+the sender of a "redo handshake" message must be prepared to receive a
+"closing connection" message instead of a "redo handshake" message; in 
+this case the sender responds with a "closing connection" message and 
+closes the connection.
+
+The handshake phase that follows a "redo handshake" message exchange 
+is a normal one in most respects; the client may request the 
+reconnection of an old session or request that a new session be 
+initiated, and the server, on receiving a reconnection request, can 
+accept the reconnection or demand that a new session be initiated 
+instead.  If a new session is being established, then both client and 
+server must request the same type of authentication requested in the 
+previous session; if one or the other was not authenticated in the 
+previous session, then requesting authentication from the 
+non-authenticated party in the new handshake phase is permitted.  Both
+parties must verify that the specifications negotiated previously in 
+the session (cipher type, key exchange type, certificate type and 
+certifier, hash function type, signature types, and so on), as well as 
+any certificates exchanged, are identical to those found in the new 
+handshake phase (with the exception of new types and certificates for 
+an authentication performed in this handshake, but not in the previous 
+one).  A mismatch results in a SPECS_MISMATCH or BAD_CERTIFICATE 
+error (see section 4.6.)  This ensures that the security properties 
+of the communication channel do not change for the worse.
+
+
+4.5  Data messages
+
+Data messages contain user data to be delivered back to the 
+application using PCT.  Each data record or datagram record contains
+exactly one data message (corresponding to the ACTUAL_DATA field 
+in the description of these records), and data messages are never 
+continued across multiple messages.
+
+PCT version 2 Data messages have the following format:
+
+char DM_MESSAGE_TYPE[2]
+char DM_MESSAGE_DATA[MESSAGE_LENGTH]
+
+The only defined MESSAGE_TYPE in PCT version 2 is DM_TYPE_USER_DATA;
+the data in messages of this type is presented directly to the 
+application.  However, implementations of PCT can assign types to 
+other values to indicate types of preprocessing, such as particular 
+compression/decompression algorithms, to be performed before passing 
+the data in MESSAGE_DATA to the application.  Such implementations
+should allow messages to be nested in the obvious way, with each 
+preprocessing step yielding another data message of the correct 
+format, and the last step yielding a data message of type  
+DM_TYPE_USER_DATA.  The permissible message types for a particular
+connection are negotiated during the handshake phase; see sections 
+5.2.1 and 5.2.2.  An unrecognized message type results in an 
+ILLEGAL_MESSAGE error (see section 4.6).
+
+For message type DM_TYPE_USER_DATA, the DM_MESSAGE_DATA field 
+contains user data to be passed to the application.  For other 
+message types, DM_MESSAGE_DATA contains data which, after the 
+preprocessing determined by the message type, yields another data 
+message.  MESSAGE_LENGTH (for the data message directly contained in
+the data or datagram record) is calculated as ACTUAL_LENGTH - 2, or 
+RECORD_LENGTH - ENCRYPTED_KEY_LENGTH - MAC_LENGTH - 6 if the message 
+is contained in a datagram record and RECORD_LENGTH - MAC_LENGTH - 4 
+if it is contained in a data record.  
+
+4.6 Error messages
+
+Error handling in the PCT protocol is very simple.  When an error is
+detected before a connection is closed, the detecting party sends a
+message to the other party indicating the error so that both parties
+will know about it, and then closes the connection.  In the case of
+closure-monitored connections (see section 4.4.3), the error message
+replaces the "closing connection" key management message.  Receiving 
+an error message also causes the receiving party to close the 
+connection.  (No "closing connection" message is ever sent in reply to 
+an error message before closure.)  
+
+Servers and clients should not make any further use of any keys, 
+challenges, connection identifiers, or session identifiers associated 
+with a connection aborted due to an error.  It is recommended that 
+implementations perform some kind of alert or logging function when 
+errors are generated to facilitate monitoring of various types of 
+attack on the system.
+
+Error messages have the following format:
+
+char ER_ERROR_TYPE[2]
+char ER_ERROR_INFO_LENGTH[2]
+char ER_ERROR_INFO_DATA[([0] << 8)|[1]]
+
+The ERROR_INFO_LENGTH field is zero except in the case of the
+SPECS_MISMATCH error message, which has a two-byte ERROR_INFO_DATA
+field.  Note that when an error message is sent before the end of
+the handshake phase of the protocol, the record containing it is left 
+unencrypted, and its MAC is omitted.
+
+The following errors are defined in PCT version 2:
+
+PCT_ERR_BAD_CERTIFICATE
+
+This error occurs when the client or server receives a handshake 
+message in which a key-exchange public key certificate is invalid, 
+either because one or more of the signatures in the certificate is 
+invalid, or because the identity or attributes on the certificate 
+are in some way incorrect.
+
+PCT_ERR_CLIENT_AUTH_FAILED
+
+This error occurs when the server receives a CLIENT_MASTER_KEY or
+CLENT_VERIFY message from the client in which the client's 
+authentication response is incorrect.  The certificate may be 
+invalid, the signature may be invalid, or the contents of the signed 
+response may be incorrect.
+
+PCT_ERR_CONN_BROKEN
+
+This error occurs when a closure-monitored connection (see section
+4.4.3) is closed without an error message or a "closing connection" 
+key management message having been received.  Since this error only
+occurs after a connection has been closed, no error message is sent.
+
+PCT_ERR_ILLEGAL_MESSAGE
+
+This error occurs under a number of circumstances.  For example, it
+occurs when an unrecognized handshake message is encountered, or when 
+the value of CH_OFFSET is to large for its CLIENT_HELLO message.
+
+PCT_ERR_INTEGRITY_CHECK_FAILED
+
+This error occurs when either the client or the server receives a
+record in which the MAC_DATA is incorrect.  It is also recommended
+that such a record be treated as if had not been received, in order 
+to ensure that applications do not receive and process invalid data
+before learning that it has failed its integrity check.  
+
+PCT_ERR_SERVER_AUTH_FAILED
+
+This error occurs when the client receives a SERVER_HELLO or
+SERVER_VERIFY message in which the authentication response is
+incorrect.
+
+PCT_ERR_SPECS_MISMATCH
+
+This error occurs when a server cannot find a cipher, hash function,
+certificate type, or key exchange algorithm it supports in the lists
+supplied by the client in the CLIENT_HELLO message.  This error may 
+also occur as a result of a mismatch in cipher specifications or 
+client authentication requests between the initial specifications and 
+those that resulted from a redo handshake sequence.
+
+The error message for this error includes a two-byte informational
+field, with eight flags defined as follows:
+
+SPECS_MISMATCH_CIPHER           = 0x0001
+SPECS_MISMATCH_HASH             = 0x0002
+SPECS_MISMATCH_EXCH             = 0x0004
+SPECS_MISMATCH_SIG              = 0x0008
+SPECS_MISMATCH_CERT             = 0x0010
+SPECS_MISMATCH_CERTIFIER        = 0x0020
+SPECS_MISMATCH_COMBINATION      = 0x0040
+
+Each flag is set if and only if the corresponding list resulted in 
+a mismatch.  For example, if and only if the SPECS_MISMATCH error 
+message is being sent because server failed to find a certificate 
+type it supports in the list supplied by the client in the 
+CH_CERT_LIST_DATA field, then the SPECS_MISMATCH_CERT flag in
+the error message would be non-zero.  The SPECS_MISMATCH_COMBINATION
+flag indicates that while there were matches found in each
+individual category, all available certificates were incompatible
+with all the type entries in at least one of the relevant lists
+(CH_CERT_LIST_DATA, CH_CERTIFIER_LIST_DATA, CH_EXCH_LIST_DATA and 
+CH_SIG_LIST_DATA).
+
+
+5. PCT Handshake Phase
+
+5.1 PCT handshake protocol overview
+
+5.1.1  PCT handshake protocol introduction
+
+The PCT Handshake Protocol (version 2) is performed during the 
+handshake phase at the start of every connection, and is used to 
+negotiate security enhancements (authentication, symmetric 
+encryption, and message integrity) to data sent during the rest of 
+the connection.
+
+The version 2 PCT Handshake Protocol consists of five messages, sent
+respectively by the client, then server, then client, then server, 
+then client, in that order.  (Moreover, under certain circumstances, 
+some or all of the last three messages are omitted.)  The messages 
+are named, in order, CLIENT_HELLO, SERVER_HELLO, CLIENT_MASTER_KEY, 
+SERVER_VERIFY, and CLIENT_VERIFY.
+
+The general contents of these messages depend upon two criteria:  
+how/if a "master key" for the session is to be exchanged, and how/if 
+each of the client and server are to be authenticated.  At least one 
+of the two must be authenticated by some means; authentication of 
+either--or both--may be based on either a key exchange, a digital 
+signature, or (for one of the two) a previously shared "password" 
+key, or, in the case of a connection in the same session as a 
+previous one, on a "master key" shared previously in the session.  
+
+The first criterion is determined by the client and server together:
+first, the CLIENT_HELLO message may contain a request to "reconnect" 
+using a previously shared master key from a particular session (in 
+which case no new key exchange is necessary).  The SERVER_HELLO 
+message will either confirm a requested continuation of the session 
+through the new connection, or require that a new session be 
+initiated, with a new key exchange.  PCT version 2 supports 
+RSA {TM} -based key exchange (see [14], [3]), Diffie-Hellman key 
+exchange (see [4], [15]) and FORTEZZA KEA token key exchange.  The 
+chosen key exchange is used by client and server in the case of a new 
+session to obtain a new shared master key.  This master key is used to 
+derive keys for encryption and message integrity (or "message 
+authentication") for the connection and for other connections 
+associated with the same session.  Note that key exchanges have an 
+implicit associated direction, with a master key being, in effect, 
+sent from one party to the other (literally in the case of RSA key 
+exchange, and more metaphorically in the case of 
+Diffie-Hellman/FORTEZZA KEA key exchange).  Hence a direction must 
+also be chosen for the exchange.  In fact, the parties may agree to 
+perform two key exchanges, one in each direction; in that case, the 
+master key for the session is computed using both of the sent keys.  
+In this document, the term "encrypted master key" refers either to an 
+RSA-encrypted master key, or to the second (typically uncertified) 
+Diffie-Hellman/FORTEZZA KEA public value sent in a Diffie-Hellman or 
+FORTEZZA KEA key exchange.  The key exchange is said to be directed 
+towards the receiver of this encrypted master key.
+
+The second criterion is determined in a similar fashion:  if the
+connection is the first of a new session, then the client may request 
+authentication of the server by key exchange, or by digital signature, 
+or by private password, or by any one of a specified subset of these 
+options.  The client also offers the server a choice among the client 
+authentication options (from among these choices) available.  The 
+server, in turn, selects a preferred authentication method if a choice 
+is offered, and may make a similar request from among the client 
+authentication options offered.  All these authentications are "linked"
+to the key exchange performed during the handshake, so that not only
+the identity of the authenticated party, but also that party's 
+association to the handshake's key exchange as performed, is verified.
+
+If no key exchange is performed, then both client and server are
+authenticated using the shared master key for the reconnected session,
+rather than any of the methods described above.
+
+In addition to key exchange and authentication, the handshake protocol
+performs two other tasks:  negotiation of cryptographic parameters, 
+and handshake verification.  The first is accomplished by the 
+CLIENT_HELLO and SERVER_HELLO messages.  The CLIENT_HELLO includes a
+list of codes for acceptable types of symmetric cipher and 
+cryptographic hash function for use during the session, as well as
+key exchange and signature algorithms, certificate types and 
+certifiers, and authentication methods acceptable for use during the 
+handshake protocol.  The server responds in the SERVER_HELLO message 
+with its choices from among these lists of acceptable types.  The 
+second task is performed during the first authentication; it is based 
+on a cryptographic hash of all the handshake message data passed up to 
+that point.  Verification of this authenticated hash value by its 
+receiver assures that the handshake was not tampered with in transit.  
+
+
+5.1.2  PCT handshake authentication
+
+The four types of authentication permissible in PCT version 2 are
+key-exchange, digital signature, private password, and reconnection.
+Each follows a particular protocol flow, which is essentially 
+independent of which party is being authenticated (except regarding
+the assignment of roles to the client and server).  In each case, 
+client and server both issue random challenges (in the CLIENT_HELLO 
+and SERVER_HELLO messages, respectively); these challenges, and
+all information exchanged up to and including the completion of 
+the key exchange(s), are incorporated into an authentication 
+response by the party being authenticated (the "responder", as 
+opposed to the "challenger", to whom the response is sent).  Hence 
+the authentication response cannot be sent until the sending of both 
+challenges, as well as the key exchange(s), have been completed 
+(although it may appear in the last message which contributes to one 
+of these).
+
+In key-exchange-based authentication, the responder sends a certified 
+public key, which the authenticating party (the "challenger") uses to 
+send a master key.  In the case of Diffie-Hellman/FORTEZZA KEA key 
+exchange, the challenger's value is normally randomly chosen, whereas 
+the responder's is fixed and certified; the master key computed by 
+the challenger can also be derived using the responder's private key 
+and the challenger's sent value.  In the case of RSA key exchange, the 
+master key is randomly chosen at the time of the key exchange by the 
+challenger and encrypted using the responder's certified public key.  
+The responder then combines the received master key (which may first 
+be combined with another sent master key, in the case of two-way key 
+exchange) with all handshake message data sent so far, including both 
+challenges and all of the key exchange data, to compute a response.  
+This response is in the form of a keyed hash, which is verified by the
+challenger to confirm that the responder could derive the master key
+correctly, and therefore holds the correct private key.  (A keyed hash
+is simply the application of a cryptographic hash function to a key 
+and some other input data; the assumed properties of the hash function 
+make the function result for any other data input infeasible to 
+compute for anyone not possessing the key.)
+
+A key-exchange-based authentication therefore has the following 
+message flow:
+
+Challenger              Responder
+----------              ---------
+
+Challenger's            Responder's
+Challenge               Challenge
+
+			[Certified public        
+			key-exchange key]
+
+Random encrypted 
+master key/public
+Diffie-Hellman value
+
+			Keyed hash response
+
+
+The challenges always appear in the CLIENT_HELLO and SERVER_HELLO
+messages.  The certified key may not need to be sent, if the 
+responder already possesses it (perhaps from a previous session).
+				    
+In signature-based authentication, the responder simply sends a 
+certified digital signature public key, accompanied by a digital
+signature, using the associated private key, of a cryptographic hash 
+of all handshake messages up to the one being sent.  (Note that this 
+value is therefore derived from the completed key exchange, as well
+as both challenges).  The challenger verifies the signature using
+the responder's certified public key.  A signature-based 
+authentication has the following message flow:
+
+Challenger              Responder
+----------              ---------
+
+Challenger's            Responder's
+Challenge               Challenge
+
+	Key Exchange(s)
+
+			Certified public
+			signature key,
+			signature response
+
+Again, the challenge messages always appear in the CLIENT_HELLO and 
+SERVER_HELLO messages.  The public key certificate may not be 
+necessary, but is sent regardless, since it can accompany the 
+digital signature in the same message, and therefore has no cost in 
+extra messages.  A certificate-identifying code may be used in its
+place if understood by both parties; see section 6.4.
+
+Password-based authentication is similar to signature-based 
+authentication; the exchanged master key is combined with the
+shared password and all the handshake message data sent so far,
+including the identity of the responder, the exchanged master key 
+and both challenges, to produce a keyed hash response which is sent 
+by the responder and verified by the challenger. 
+
+A special case of this authentication is a doubly-certified 
+Diffie-Hellman key exchange, in which one party  is authenticated by 
+certified Diffie-Hellman key-exchange public key, and the challenger's 
+sent value is not random but rather another certified Diffie-Hellman 
+public key.  In this case, the challenger's identity is represented 
+by the certificate for the public value sent, and the exchanged 
+master key received by the responder is also treated simultaneously 
+as the challenger's password.  (If both parties are to be 
+authenticated by certified Diffie-Hellman key exchange, then each 
+sends a randomly chosen public value to the other, and the final 
+master key is obtained by combining the two keys exchanged.) 
+
+It is recommended that shared private keys used for password-based
+authentication be machine-generated and cryptographically random in 
+the same sense as the master key (see section 6.1.3).  However, 
+because the distribution of password-style shared private keys is
+outside the scope of this protocol, and is therefore vulnerable to 
+possible insecure implementations, the following constraints on 
+password-based authentication are imposed:  
+
+1.  Only one of the client and server, not both, may be 
+authenticated using password-based authentication.
+
+2.  Password-based authentication may only be used if the other party 
+is also authenticated, using either key exchange- or signature-based 
+authentication.
+
+3.  If the other party is authenticated using signature-based 
+authentication, then the password-based authentication response must 
+be sent only after the other party's authentication response has been 
+sent and verified.
+
+These constraints protect poorly chosen password-style shared private 
+keys from off-line brute force attacks.  However, even a well-chosen
+shared private key is vulnerable if not kept strictly confidential
+by both parties sharing it.  Implementations must therefore ensure 
+this confidentiality.  Poorly-chosen or poorly-guarded passwords are
+of course still vulnerable to other attacks.
+
+A password-based authentication has the following message flow:
+
+Challenger              Responder
+----------              ---------
+
+Challenger's            Responder's
+Challenge               Challenge
+
+	Key Exchange(s)
+
+			responder's identity/
+			certified D-H public
+			value, keyed hash response
+
+
+Finally, in the case of authentication based on a master key exchanged
+earlier in the session, the response is computed from both challenges,
+the shared master key, and the session identifier.  (The client's 
+response is in fact implicit; by computing a correct MAC for its first
+data message, the client demonstrates its possession of the session's
+master key.)  This authentication has the following flow:
+
+Challenger              Responder
+----------              ---------
+
+Challenger's            Responder's
+Challenge               Challenge
+
+			keyed hash response
+
+
+5.1.3  Handshake key exchange
+
+In the full handshake protocol, authentications are interleaved with 
+at least one key exchange (and with each other, if both client and 
+server are being authenticated).  The interleaving is designed to 
+compress the authentications and key exchange(s) into as few 
+messages as possible.  For example, a client has the option of 
+sending an encrypted public key and/or (possibly certified) 
+key-exchange public key in the CLIENT_HELLO message, along with its 
+challenge.  The latter allows the client to "receive" a 
+client-directed key exchange, while the former initiates a 
+server-directed key exchange.  However, the client may not have the 
+server's key-exchange public key, and may not anticipate a request for 
+a client-directed key exchange; hence, sending of the encrypted master 
+key and/or client key-exchange certificate may be postponed to the 
+CLIENT_MASTER_KEY message.
+
+In general, each possible key exchange has a "regular" and "quick"
+flow.  A client-directed key exchange may occur beginning in the
+CLIENT_MASTER_KEY message, when the client sends a (possibly 
+certified) key-exchange public key, then continues in the 
+SERVER_VERIFY message with the server sending an encrypted master 
+key.  In the quick version, the client may (or may not) send the 
+(certified) public key in the CLIENT_HELLO message, and the server, 
+upon receiving it (or having received it at some time in the past) 
+sends an encrypted master key in the SERVER_HELLO message.  Similarly, 
+normal server-directed key exchange begins in the SERVER_HELLO message
+with a (possibly certified) key-exchange public key, and continues 
+with an encrypted master key in the following CLIENT_MASTER_KEY 
+message.  In the quick version, the client, having received the 
+server's public key previously, sends an encrypted master key 
+immediately, in the CLIENT_HELLO message.
+
+5.1.4  PCT Handshake Protocol flow
+
+The contents of PCT version 2 handshake protocol can be summarized as
+follows:
+
+The CLIENT_HELLO message contains a random authentication challenge
+to the server and a request for the type and level of cryptography,
+certification, authentication and (if necessary) digital signature
+to be used for the session, if it is to be a new one.  If the client 
+is attempting to continue an old session, then it also supplies that 
+session's identifier.  The client can also send a "quick 
+certificate", in anticipation of a client authentication request from 
+the server, and even a "quick master key", if the client already has 
+a satisfactory server's key-exchange public key.
+
+If the server accepts the old session identifier, then the 
+SERVER_HELLO message contains a response to the client's challenge, 
+and a random connection identifier which doubles as a random challenge
+to the client.  The handshake is then finished (although an 
+authentication of the client is implicit in the MAC included with the 
+client's first data message).  
+
+In the case of a new session, the SERVER_HELLO message contains a
+random connection identifier; this identifier doubles as an 
+authentication challenge to the client if the server desires client 
+authentication.  The server also responds with its choices for type 
+and level of cryptography, certification, authentication and (if 
+necessary) digital signature (from among those offered by the 
+client).  In addition, the server sends a certificate for the type of 
+authentication requested by the client (if any), and sends a "quick 
+master key" and/or "quick response" in response to the client's 
+"quick certificate" and/or "quick master key", respectively, if 
+appropriate.  In the latter case, the response may require an
+accompanying digital signature public-key certificate or "identity
+indicator" (directing the client to the correct shared password), 
+and the handshake protocol completes at this point if no client 
+authentication is required.  
+
+The CLIENT_MASTER_KEY message sent by the client (assuming that it
+is necessary) includes a (possibly certified) key-exchange public key, 
+if requested by the server.  It also contains an encrypted master key,
+if the server sent a key-exchange public key, and an authentication 
+response (accompanied by an identity indicator or digital signature 
+public key certificate, if appropriate) if client authentication by 
+signature or password was requested, and the key exchange has been 
+completed.  If the server's authentication response has also been 
+received (or was not required), then the handshake protocol completes 
+at this point.
+
+The SERVER_VERIFY message sent next by the server, if necessary, 
+contains an encrypted master key sent to the client, if requested,
+and/or an authentication response (possibly accompanied by a digital
+signature public key certificate or identity indicator) to the 
+encrypted master key sent in the previous message.  Unless the former 
+requires an authentication response, the protocol completes at this
+point.
+
+Finally, the CLIENT_VERIFY message, if needed, contains the client's 
+authentication response to the key exchange completed by the 
+encrypted master key sent in the SERVER_VERIFY message. 
+
+Usually the client or server can safely begin sending data records 
+on the underlying transport immediately following its own last 
+handshake message, without waiting for a response even if one is 
+expected.  In most instances, therefore, PCT adds only a single
+round-trip to the connection's setup cost.  Sometimes the cost is
+even less; for instance, a server can begin sending data immediately
+after sending the SERVER_HELLO message if the client initiated a 
+quick server-directed key exchange and only server authentication
+is required, or if a successful reconnection of an established 
+session has occurred (note that in this case the client cannot send 
+data until receiving the SERVER_HELLO message containing the server's 
+challenge).
+
+
+5.2  PCT Handshake messages
+
+PCT version 2 Handshake messages are sent in handshake records, whose
+format is described in section 4.3.1.  These records are sent in the 
+clear (unencrypted), although some of the key-exchange-related fields 
+involve (public-key) encryption.  A single handshake message may span
+across more than one handshake record; however, only data fields 
+associated with four-byte length fields may do so.  These fields are 
+always the last ones in a message; the remaining ones (including all 
+length fields) must be contained within the first handshake record 
+used for the handshake message.  (Note that for PCT version 1 
+compatibility reasions, the CLIENT_HELLO message has no such fields.)
+
+5.2.1 CLIENT_HELLO 
+
+char CH_SESSION_ID_DATA[30]
+char CH_CHALLENGE_DATA[30]
+char CH_CLIENT_VERSION[2]
+char CH_OFFSET[2]
+char CH_CIPHER_LIST_LENGTH[2]
+char CH_HASH_LIST_LENGTH[2]
+char CH_CERT_LIST_LENGTH[2]
+char CH_EXCH_LIST_LENGTH[2]
+char CH_KEY_ARG_LENGTH[2]
+char CH_MSG_LIST_LENGTH[2]
+char CH_SIG_LIST_LENGTH[2]
+char CH_CERTIFIER_LIST_LENGTH[2]
+char CH_QUICK_PUBLIC_VALUE_LENGTH[2]
+char CH_QUICK_SERVER_PUBLIC_VALUE_LENGTH[2]
+char CH_QUICK_ENCRYPTED_KEY_LENGTH[2]
+char CH_AUTH_OPTIONS[2]
+char CH_CIPHER_LIST_DATA[([0] << 8)|[1]]
+char CH_HASH_LIST_DATA[([0] << 8)|[1]]
+char CH_CERT_LIST_DATA[([0] << 8)|[1]]
+char CH_EXCH_LIST_DATA[([0] << 8)|[1]]
+char CH_KEY_ARG_DATA[([0] << 8)|[1]]
+char CH_MSG_LIST_DATA[([0] << 8)|[1]]
+char CH_SIG_LIST_DATA[([0] << 8)|[1]]
+char CH_CERTIFIER_LIST_DATA[([0] << 8)|[1]]
+char CH_QUICK_PUBLIC_VALUE_DATA[([1] << 8)|[1]]
+char CH_QUICK_SERVER_PUBLIC_VALUE_DATA[([0] << 8)|[1]]
+char CH_QUICK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
+
+When a client first connects to a server it is required to send the
+CLIENT_HELLO message.  The server is expecting this message from the
+client as its first message. It is an ILLEGAL_MESSAGE error for a
+client to send anything else as its first message.  The CLIENT_HELLO
+message begins with two fixed-length fields followed by a two-byte 
+version number and an offset to the variable length data.  The 
+version number field CH_CLIENT_VERSION is always set to 
+PCT_VERSION_V2 in PCT version 2.  The CH_OFFSET field contains the 
+number of bytes used by the various fields (length fields plus the 
+AUTH_OPTIONS field) that follow the offset field and precede the 
+variable-length fields.  For PCT version 2, this offset value is 
+always PCT_CH_OFFSET_V2, i.e., 24.  However, inclusion of this field 
+will allow future versions to be compatible with version 2, even if 
+the number of these fields changes, just as inclusion of this field 
+helps make PCT version 2 CLIENT_HELLO messages understandable to PCT 
+version 1 servers.
+
+The CH_CHALLENGE_DATA field is a string of 30 bytes of random bits, to
+be used as authentication challenge data from the client.  The 
+CHALLENGE_DATA should be cryptographically random, in the same sense 
+as the MASTER_KEY (see section 6.1.3).  If the client finds a 
+session identifier in its cache for the server, then that 
+session-identifier data is sent in the field CH_SESSION_ID_DATA.  
+Otherwise, the special PCT_SESSION_ID_NONE value is used.  In either 
+case, the client specifies in CIPHER_LIST_DATA, HASH_LIST_DATA,
+EXCH_LIST_DATA and SIG_LIST_DATA its preferred choices of symmetric 
+cipher, key lengths, hash function, asymmetric key exchange algorithm
+and digital signature algorithm.  However, if a session identifier is 
+sent, then these choices are only relevant in the case where the 
+server cannot recognize the session identifier, and a new session 
+must therefore be initiated.  If the server recognizes the session, 
+then these fields are ignored by the server.  Similarly, if the 
+client requires server authentication in the event of a new session 
+initiation, then the CERT_LIST_DATA and CERTIFIER_LIST_DATA lists 
+contain the client's preferred choices of certificate type and 
+certifier; otherwise, these lists are empty, and their length is 
+zero.  Finally, the MSG_LIST_DATA list contains a list of data
+message types (other than the DM_TYPE_USER_DATA) supported by the 
+client; if the client supplies a session identifier and the server
+recognizes it, then this list is ignored, and the list negotiated
+previously in the session is used instead.
+
+The AUTH_OPTIONS field contains the values of twelve flags that 
+determine the flow of the remainder of the protocol if a new session 
+is being initiated.  The flags are associated with the twelve 
+low-order bits of the AUTH_OPTIONS field, and are named, in order 
+(from least to most significant bit), as follows:
+
+CH_DEMAND_KEY_EXCH_SEND     :=  0x0001
+CH_DEMAND_AUTH_KEY_EXCH     :=  0x0002
+CH_DEMAND_AUTH_SIG          :=  0x0004 
+CH_DEMAND_AUTH_PASSWORD     :=  0x0008 
+CH_OFFER_KEY_EXCH_RECEIVE   :=  0x0010
+CH_OFFER_AUTH_KEY_EXCH      :=  0x0020
+CH_OFFER_AUTH_SIG           :=  0x0040 
+CH_OFFER_AUTH_PASSWORD      :=  0x0080
+CH_REQUEST_RECONNECT        :=  0x0100
+CH_REQUEST_CLOSURE_MON      :=  0x0200
+CH_REQUEST_REDO_ENABLE      :=  0x0400
+CH_OFFER_CERTIFIER_TRYOUT   :=  0x0800
+
+If the CH_DEMAND_KEY_EXCH_SEND flag is set to one, then the client
+requires that the server accept an encrypted master key from the 
+client as part of the key exchange.  If the CH_OFFER_KEY_EXCH_RECEIVE 
+flag is set to one, then the client is willing to receive an encrypted 
+master key from the server as part of the key exchange.  If both flags
+are set, then both conditions hold; the client requires that the 
+server receive a key exchange, and will also accept one, at the 
+server's option.  In the case of uncertified Diffie-Hellman/FORTEZZA 
+KEA key exchange, the flags simply refer to the "receiver" sending the 
+public value first, followed by the "sender"; in other cases, the 
+holder of the private key associated with the RSA public key or 
+certified Diffie-Hellman/FORTEZZA KEA public value is always the 
+"receiver".  (Doubly certified Diffie-Hellman/FORTEZZA KEA key 
+exchange is discussed in section 5.1.2.)  Note that both client and 
+server are assumed willing to be the (possibly sole) sender of an 
+encrypted master key; hence, even if the CH_DEMAND_KEY_EXCH_SEND flag 
+is set to zero, and the CH_OFFER_KEY_EXCH_RECEIVE flag is set to one, 
+the client has neither ruled out being the sender, nor demanded to be 
+the receiver, of an encrypted master key.  
+
+The six AUTH flags refer to types of authentication:  the client
+requires the server to authenticate by one of the means for which the
+associated CH_DEMAND_AUTH flag is set to one, and offers to 
+authenticate itself, at the server's option, by any of the means for 
+which the associated CH_OFFER_AUTH flag is set to one.  (The
+abbreviations "KEY_EXCH", "SIG" and "PASSWORD" stand for 
+key-exchange-based, digital signature-based and shared password-based
+authentication, respectively.)  The settings of the flags must be
+consistent with at least one key exchange and one authentication 
+occurring; i.e., at least one of the six authentication flags and at 
+least one of the two key exchange flags must be set to one.  Moreover,
+the constraints on password-based authentication must be obeyed.  (See
+sections 5.1.2 and 7.2.)
+
+The CH_REQUEST_RECONNECT flag indicates, when set to one, that the 
+client is requesting that the current connection be part of an 
+existing session; in this case, the CH_SESSION_ID field must contain
+that session's identifier.  The CH_REQUEST_CLOSURE_MON flag 
+indicates, when set to one, that the client wishes the current session 
+to be closure-monitored (see section 4.4.3).  The 
+CH_REQUEST_REDO_ENABLE flag indicates, when set to one, that the 
+client wishes the current session to be redo-enabled (see section 
+4.4.4).  Finally, the CH_OFFER_CERTIFIER_TRYOUT flag indicates, when
+set to one, that the list of acceptable certifiers in 
+CH_CERTIFIER_LIST is not exhaustive (see below).
+ 
+The CIPHER_LIST_DATA field contains a list of possible symmetric
+ciphers supported by the client, in order of (the client's)
+preference.  Each element in the list is a four-byte field, of which
+the first two bytes contain a code representing a cipher type, the
+third byte contains the encryption key length in bits (0-255), and the
+fourth byte contains the MAC key length in bits, minus 64 (values
+0-255, representing lengths 64-319; this encoding enforces the
+requirement that the MAC key length be at least 64 bits).  The entire
+list's length in bytes (four times the number of elements) is placed
+in CIPHER_LIST_LENGTH.
+
+The HASH_LIST_DATA field contains a list of possible hash functions
+supported by the client, in order of (the client's) preference.  The
+server will choose one of these to be used for computing MACs and
+deriving keys.  Each element in the list is a two-byte field
+containing a code representing a hash function choice.  The entire
+length of the list (twice the number of elements) is placed in
+HASH_LIST_LENGTH.
+
+The CERT_LIST_DATA field contains a list of possible certificate
+formats supported by the client, in order of (the client's)
+preference.  Each element in the list is a two-byte field containing a
+code representing a certificate format.  The entire length of the list
+(twice the number of elements) is placed in CERT_LIST_LENGTH.
+
+The EXCH_LIST_DATA field contains a list of possible asymmetric key
+exchange algorithms supported by the client, in order of (the
+client's) preference.  Each element in the list is a two-byte field
+containing a code representing a key exchange algorithm type.  The 
+entire length of the list (twice the number of elements) is placed 
+in EXCH_LIST_LENGTH.
+
+The KEY_ARG_DATA field contains an initialization vector to be used in
+a reconnected session when the cipher type is a block cipher (see 
+section 6.1.5).  If a new session is being requested (i.e., if the 
+CH_REQUEST_RECONNECT flag is set to zero), then KEY_ARG_LENGTH must 
+be zero.
+
+The MSG_LIST_DATA field contains a list of data message types (other
+than DM_TYPE_USER_DATA) supported by the client.  Each element in the
+list is a two-byte field containing a code representing a data message
+type.  The entire length of the list (twice the number of elements) is
+placed in MSG_LIST_LENGTH.
+
+The SIG_LIST_DATA field contains a list of possible signature 
+algorithms supported by the client, in order of (the client's) 
+preference.  Each element in the list is a two-byte field containing 
+a code representing a signature algorithm type.  The entire length 
+of the list (twice the number of elements) is placed in 
+SIG_LIST_LENGTH.
+
+The CERTIFIER_LIST_DATA field contains a list of identifiers of 
+possible certificate sources recognized by the client, in order of 
+(the client's) preference.  Each element in the list is a 
+zero-delimited string.  The entire length of the list is placed in 
+CERTIFIER_LIST_LENGTH.  A client may indicate, by setting the 
+CH_OFFER_CERTIFIER_TRYOUT flag to one, that the certifier list does
+not imply rejection of all other certifiers; for example, the client
+may provide an abbreviated (or even empty) certifier list to avoid 
+constructing an exhaustive list of accepted certifiers, or may lack 
+a naming convention for certifiers known to be compatible with that 
+of the server.  The client may still in that case reject a 
+certificate offered by the server.
+
+The CH_QUICK_PUBLIC_VALUE_DATA field may, at the client's option, 
+contain a (possibly certified) key-exchange public key.  If the 
+field is non-empty, then the CH_OFFER_KEY_EXCH_RECEIVE flag must 
+be set to one.  If the CH_OFFER_AUTH_KEY_EXCH flag is also set to 
+one, then the CH_QUICK_PUBLIC_VALUE_DATA field, if non-empty, 
+contains a certificate (including key-exchange public key); otherwise 
+the field, if non-empty, contains an uncertified key exchange public 
+value.  The exact format of this field is described in section 
+6.1.2.  If the client expects the server to demand client 
+authentication by key exchange, then this public key/certificate may 
+expedite the expected key exchange/authentication; however, the server
+may still indicate in the subsequent SERVER_HELLO message that a 
+public key or certificate of another type (or from a different 
+certifier) is required.
+
+The CH_QUICK_SERVER_PUBLIC_VALUE_DATA and CH_QUICK_ENCRYPTED_KEY_DATA 
+fields may, at the client's option, contain, respectively, the public
+value from a key-exchange public key certificate attributed to the 
+server, and an encrypted master key (or Diffie-Hellman/FORTEZZA KEA 
+public value) decryptable by the holder of the private key associated 
+with the certified key-exchange public key.  The format of these 
+fields is described in section 6.1.2.  If the client already 
+possesses a certified key-exchange public key belonging to the server,
+then use of these fields will expedite the resulting key exchange.  
+However, in unusual circumstances, the server may still "disavow" the 
+key exchange--that is, refuse to receive it, and offer only some 
+other key exchange type, direction or certificate.  (For example, the 
+public key used by the client may be incorrect or out-of-date.)  Note 
+that if these fields are used by the client, then the 
+CH_REQUEST_KEY_EXCH_SEND flag must be set to one.  
+
+The server, on receiving a CLIENT_HELLO message, checks the version
+number and the offset field to determine where the variable-length
+data fields start.  (The OFFSET value should be at least
+PCT_CH_OFFSET_V2 for versions 2 and higher.)  The server then checks 
+whether the CH_REQUEST_RECONNECT flag is set to one, and if so, 
+whether it recognizes the SESSION_ID.  In that case, the server 
+responds with a SERVER_HELLO message with the SH_ACCEPT_RECONNECT 
+flag set, and the appropriate values (see below) in the RESPONSE and 
+CONNECTION_ID fields.  
+
+Otherwise, it examines the CIPHER_LIST and HASH_LIST lists in the 
+CLIENT_HELLO message to select a cipher and hash function.  The 
+server also examines the AUTH_OPTIONS flags and CERT_LIST, 
+CERTIFIER_LIST, SIG_LIST and EXCH_LIST lists to select a key 
+exchange type and direction(s) and an authentication combination for 
+itself (including authentication type, certificate type and 
+certifier) which is acceptable to both the client and the server, if 
+one or more of the CH_DEMAND_AUTH flags were set.  Finally, the 
+server examines the same lists to choose a sublist from each with 
+which it is compatible, if it requires client authentication as well.  
+If such selections are possible, then the server sends a SERVER_HELLO 
+message to the client as described below; otherwise, the server 
+detects a SPECS_MISMATCH error.   The server also examines the quick
+key-exchange public value (if sent) for compatibility, and/or 
+decrypts the quick encrypted master key, if possible.
+
+
+5.2.2 SERVER_HELLO  
+
+char SH_SERVER_VERSION[2]
+char SH_AUTH_OPTIONS[2]
+char SH_CIPHER_SPECS_DATA[4]
+char SH_HASH_SPECS_DATA[2]
+char SH_EXCH_SPECS_DATA[2]
+char SH_CONNECTION_ID_DATA[30]
+char SH_SESSION_ID_DATA[30]
+char SH_ALT_CIPHER_LIST_LENGTH[2]
+char SH_ALT_HASH_LIST_LENGTH[2]
+char SH_MSG_LIST_LENGTH[2]
+char SH_EXCH_LIST_LENGTH[2]
+char SH_CERT_LIST_LENGTH[2]
+char SH_SIG_LIST_LENGTH[2]
+char SH_QUICK_ENCRYPTED_KEY_LENGTH[2]
+char SH_RESPONSE_LENGTH[2]
+char SH_CERTIFIER_LIST_LENGTH[4]
+char SH_PUBLIC_VALUE_LENGTH[4]
+char SH_SIG_CERT_LENGTH[4]
+char SH_ALT_CIPHER_LIST_DATA[([0] << 8)|[1]]
+char SH_ALT_HASH_LIST_DATA[([0] << 8)|[1]]
+char SH_MSG_LIST_DATA[([0] << 8)|[1]]
+char SH_EXCH_LIST_DATA[([0] << 8)|[1]]
+char SH_CERT_LIST_DATA[([0] << 8)|[1]]
+char SH_SIG_LIST_DATA[([0] << 8)|[1]]
+char SH_QUICK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
+char SH_RESPONSE_DATA[([0] << 8)|[1]]
+char SH_CERTIFIER_LIST_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+char SH_PUBLIC_VALUE_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+char SH_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+
+The server sends this message after receiving the client's
+CLIENT_HELLO message.  The PCT version number in SH_SERVER_VERSION 
+is always the maximum protocol version that the server supports; the 
+remainder of the SERVER_HELLO message and all subsequent messages 
+will conform to the format specified by the protocol version 
+corresponding to the minimum of the client and server protocol 
+version numbers, as indicated by the CH_CLIENT_VERSION and 
+SH_SERVER_VERSION fields.  Unless there is an error, the server always 
+returns a random value 30 bytes in length in the CONNECTION_ID field.  
+This value doubles as challenge data if the server requests client 
+authentication, and should therefore be random in the same sense as 
+the challenge data in the CLIENT_HELLO message.
+
+The SH_AUTH_OPTIONS field contains twelve flags, associated with the
+twelve low-order bits of the SH_AUTH_OPTIONS field; they are named,
+in order (from least to most significant bit), as follows:
+
+SH_ACCEDE_KEY_EXCH_RECEIVE  :=  0x0001
+SH_ACCEDE_AUTH_KEY_EXCH     :=  0x0002
+SH_ACCEDE_AUTH_SIG          :=  0x0004 
+SH_ACCEDE_AUTH_PASSWORD     :=  0x0008 
+SH_ACCEPT_KEY_EXCH_SEND     :=  0x0010
+SH_ACCEPT_AUTH_KEY_EXCH     :=  0x0020
+SH_ACCEPT_AUTH_SIG          :=  0x0040 
+SH_ACCEPT_AUTH_PASSWORD     :=  0x0080
+SH_ACCEPT_RECONNECT         :=  0x0100
+SH_ACCEPT_CLOSURE_MON       :=  0x0200
+SH_ACCEPT_REDO_ENABLE       :=  0x0400
+SH_OFFER_CERTIFIER_TRYOUT   :=  0x0800
+
+The SH_ACCEPT_CLOSURE_MON flag is set to one if and only if the 
+CH_REQUEST_CLOSURE_MON flag is set to one, and the server also 
+prefers the current connection to be closure-monitored (see section
+4.4.3).  The SH_ACCEPT_REDO_ENABLE flag is set to one if and only if
+the CH_REQUEST_REDO_ENABLE flag is set to one, and the server also
+prefers the current connection to be redo-enabled (see section 4.4.4).
+
+If the server recognizes the contents of the CH_SESSION_ID_DATA 
+field of the CLIENT_HELLO message as session identifier for a session
+for which the master key is still available to the server, then the
+SH_ACCEPT_RECONNECT flag in the SH_AUTH_OPTIONS field is set to one.
+Also, the SH_SESSION_ID_DATA field echoes the CH_SESSION_ID_DATA 
+field.  Moreover, the server sets the CIPHER_SPECS_DATA and 
+HASH_SPECS_DATA fields to the values stored along with the session 
+identifier.  There are two subcases:  (1) If the SH_EXCH_SPECS_DATA 
+value does not refer to a TOKEN type (see section 6.1), then the 
+CLIENT_MAC, SERVER_MAC, CLIENT_WRITE, and SERVER_WRITE keys are 
+rederived using the MASTER_KEY from the old session, as well as the 
+CONNECTION_ID and CH_CHALLENGE values from the SERVER_HELLO and 
+CLIENT_HELLO messages, respectively, for this connection.  (2) If the 
+SH_EXCH_SPECS_DATA refers to a TOKEN type, then the keys from the 
+ongoing session continue to be used.  In order to obtain fresh key 
+material or reset the sequence number, TOKEN implementations must use 
+the redo handshake mechanism (KM_REDO_HANDSHAKE key management 
+message), or else not request (or not accept) reconnections of an 
+established session.  When this mechanism is used with a TOKEN 
+exchange type, the client must set the CH_REQUEST_RECONNECT flag to
+one and send PCT_SESSION_ID_NONE in the CH_SESSION_ID_DATA field of 
+the subsequent CLIENT_HELLO message.  (See section 4.4.4.)
+
+In the case of a reconnection, all the remaining data fields are 
+empty except for SH_RESPONSE_DATA, whose contents are described in 
+section 7.2.  Also, all of the flags in SH_AUTH_OPTIONS are set to 
+zero except SH_ACCEPT_RECONNECT and possibly SH_ACCEPT_CLOSURE_MON 
+and/or SH_ACCEPT_REDO_ENABLE.
+       
+If the server does not recognize the session identifier provided by
+the client (or if the CH_REQUEST_RECONNECT flag was set to zero), 
+then the server sets the SH_ACCEPT_RECONNECT flag to zero in the 
+SH_AUTH_OPTIONS field.  A unique session identifier (which must not 
+equal PCT_SESSION_ID_NONE) is also placed in the SH_SESSION_ID_DATA 
+field; this value need not be cryptographically random, but values 
+should not be used repeatedly (a continually increasing counter, for 
+instance, would be sufficient).  The server then selects any choice 
+with which it is compatible, from each of the CH_CIPHER_LIST, 
+CH_HASH_LIST and CH_EXCH_LIST lists supplied in the CLIENT_HELLO 
+message.  (These values are returned to the client in the 
+SH_CIPHER_SPECS_DATA, SH_HASH_SPECS_DATA and SH_EXCH_SPECS_DATA 
+fields, respectively.)  If no cipher type (respectively, hash type, 
+key exchange type) from the CH_CIPHER_LIST (respectively, 
+CH_HASH_LIST, CH_EXCH_LIST) is acceptable to the server, then a 
+SPECS_MISMATCH error occurs.
+
+Alternate cipher and hash types from CH_CIPHER_LIST and CH_HASH_LIST, 
+respectively, with which the server is compatible may be placed in the 
+SH_ALT_CIPHER_LIST and SH_ALT_HASH_LIST lists (whose formats are 
+identical to those of CH_CIPHER_LIST and CH_HASH_LIST, respectively); 
+these lists can then be used by the client in determining whether 
+pre-encrypted, pre-MAC'd data will be understandable to the server.  
+(Filling these lists is optional for the server; an empty list simply 
+means that the client has no assurance that the server supports any 
+cipher or hash type other than the one selected for the session.)  
+Finally, the SH_MSG_LIST list contains a list of those data message 
+types from CH_MSG_LIST which the server also supports; the format of 
+the two message type lists is identical.
+
+The server also examines the CH_AUTH_OPTIONS flags to select server 
+authentication and key exchange options acceptable to both (as 
+indicated by the CH_AUTH_OPTIONS flags and the server's own 
+requirements/compatibilities), and to offer a set of acceptable
+client authentication options.  In particular, these must include a 
+server authentication type if any of the CH_DEMAND_AUTH flags is set 
+to one, at least one client authentication type if client 
+authentication is required by the server, and a key exchange 
+direction (or two) acceptable to both client and server, as indicated 
+by the CH_DEMAND_KEY_EXCH_SEND and CH_OFFER_KEY_EXCH_RECEIVE flags 
+and the server's own requirements.  (The restrictions on 
+password-based authentication must also be obeyed; see section 5.1.2.)
+If no such set of types is available that is acceptable to both client
+and server, then a SPECS_MISMATCH error occurs.  If at least one such 
+set of types is found, then the server sets the associated flags in 
+SH_AUTH_OPTIONS (at most one SH_ACCEDE_AUTH flag and at least one 
+SH_ACCEDE/ACCEPT_KEY_EXCH flag); these determine the type of server 
+authentication to be performed, if any, and the direction of the key 
+exchange(s), as well as the set of client authentication options 
+acceptable to the server.  The type of the key exchange(s) (they must 
+both be of the same type, if there are two) is selected by the server,
+and indicated by the code in the SH_EXCH_SPECS field.
+
+If the server requires client authentication, then the server also
+selects those choices from the CH_SIG_LIST, CH_CERT_LIST and 
+CH_CERTIFIER_LIST lists that are also acceptable 
+CH_OFFER_CERTIFIER_TRYOUT is set to one).  These server-selected 
+lists are placed in the SH_SIG_LIST_DATA, SH_CERT_LIST_DATA and 
+SH_CERTIFIER_LIST_DATA fields, respectively; their format is 
+identical to those of the corresponding fields in the CLIENT_HELLO 
+message.  If the server does not require client authentication, then 
+the SH_SIG_LIST, SH_CERT_LIST and SH_CERTIFIER_LIST fields are 
+empty, and their length is zero.  The server may also, like the 
+client, demand certificate-based authentication but set the 
+SH_OFFER_CERTIFIER_TRYOUT flag to one.  In this case, the server 
+simply reserves the right to reject certificates from unacceptable 
+certifiers, and its list of acceptable ones is not assumed 
+exhaustive.
+
+If the SH_ACCEDE_KEY_EXCH_RECEIVE flag is set to one and the
+CH_QUICK_SERVER_CERT field is either empty or contains an 
+incorrect public value, then the SH_PUBLIC_VALUE_DATA field contains 
+a (possibly certified) key-exchange public key of a type compatible 
+with the chosen key exchange type specified in the 
+SH_EXCH_SPECS_DATA field.  If, moreover, the 
+SH_ACCEDE_AUTH_KEY_EXCH flag is set to one, then the key-exchange 
+public key is contained in a certificate whose type and certifier 
+are found in the CH_CERT_LIST and CH_CERTIFIER_LIST lists, 
+respectively (if CH_CERTIFIER_LIST is non-empty).  Otherwise, the 
+public key is uncertified.  The format of the SH_PUBLIC_VALUE_DATA
+field is described in section 6.1.2.  If the 
+SH_ACCEDE_KEY_EXCH_RECEIVE flag is set to zero, then the 
+SH_PUBLIC_VALUE_DATA field is empty, and its length is zero.
+
+If the client sent an acceptable key-exchange public key certificate
+in the CH_QUICK_PUBLIC_VALUE field of the CLIENT_HELLO message, then 
+the server responds with an RSA-encrypted master key (or randomly 
+chosen Diffie-Hellman/FORTEZZA KEA public value) in the 
+SH_QUICK_ENCRYPTED_KEY field of the SERVER_HELLO message.  (The 
+format of this field is described in section 6.1.2.)
+
+If the client sent an acceptable certified server key-exchange 
+public key and encrypted master key in the CH_QUICK_SERVER_CERT and 
+CH_QUICK_ENCRYPTED_KEY fields of the CLIENT_HELLO message, and if the 
+SH_ACCEPT_KEY_EXCH_SEND flag in the SH_AUTH_OPTIONS field is set to
+zero, then the key exchange is completed, and the server must place an
+authentication response, constructed as described in section 7.2, in 
+SH_RESPONSE_DATA if one of the CH_DEMAND_AUTH flags is set to one.  If 
+the SH_ACCEDE_AUTH_SIG flag is set to one, then the SH_SIG_CERT_DATA 
+field contains a certified digital signature public key acceptable to 
+the client (as indicated by the CH_SIG_LIST, CH_CERT_LIST and 
+CH_CERTIFIER_LIST lists), in the format of a PUBLIC_VALUE field of
+type PV_CERTIFICATE (see section 6.1.2).  If the 
+SH_ACCEDE_AUTH_PASSWORD flag is set to one, then an identity indicator 
+(such as an account identifier or, in the case of doubly certified 
+Diffie-Hellman key exchange, a certificate for the Diffie-Hellman 
+public value supplied by the server in the key exchange) is placed in 
+the SH_SIG_CERT_DATA field.  Otherwise the SH_SIG_CERT_DATA field is 
+empty, and its length is zero.  
+
+When the client receives a SERVER_HELLO message, it checks whether the
+server has accepted a reconnection of an old session or is
+establishing a new session.  If the session is an old one, then the 
+client establishes the new CLIENT_WRITE_KEY, SERVER_WRITE_KEY, 
+CLIENT_MAC_KEY and SERVER_MAC_KEY according to the cipher-specific 
+rules described in section 6.1.4.  The client then checks the 
+contents of the RESPONSE_DATA field in the SERVER_HELLO message for 
+correctness.  If the response exactly matches the value calculated by 
+the client (following the procedures in sections 7.1 and 7.2), then 
+the handshake is finished, and the client proceeds to the 
+CLIENT_MASTER_KEY messsage, if necessary, or else begins sending 
+data; otherwise, a SERVER_AUTH_FAILED error occurs.
+
+If a new session is being initiated, the client records the chosen
+cipher, hash, key exchange and signature types, and the lists of
+alternate cipher and hash types and supported data message types.
+If certificate-based client authentication is required the client 
+checks the list of certificate types and certifiers to see if it has
+a satisfactory certificate; lack of one results in a SPECS_MISMATCH
+error.  If an acceptable quick encrypted master key was sent, the 
+client decrypts the master key for use in obtaining a MAC_KEY and 
+WRITE_KEY for each transmission direction as described in section 
+6.1.4.  Finally, if a non-empty RESPONSE_DATA field was included, then
+the client checks it for correctness.   If it exactly matches the 
+value calculated by the client (following the procedures in sections 
+7.1 and 7.2), then the client proceeds to the CLIENT_MASTER_KEY 
+handshake message (or, if the handshake is completed, begins sending 
+data); otherwise, a SERVER_AUTH_FAILED error occurs.
+
+
+5.2.3 CLIENT_MASTER_KEY 
+
+char CMK_ENCRYPTED_KEY_LENGTH[2]
+char CMK_RESPONSE_LENGTH[2]
+char CMK_SIG_CERT_LENGTH[4]
+char CMK_PUBLIC_VALUE_LENGTH[4]
+char CMK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
+char CMK_RESPONSE_DATA[([0] << 8)|[1]]
+char CMK_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+char CMK_PUBLIC_VALUE_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+
+The client sends this message after receiving the SERVER_HELLO message
+from the server if not all the key exchanges and authentications (as
+indicated by the SH_AUTH_OPTIONS field) have yet been completed.
+
+If SH_ACCEPT_AUTH_SIG is set to one, and no other client 
+authentication option is both acceptable to the server and preferred
+by the client, then CMK_SIG_CERT_DATA contains a certified digital 
+signature public key acceptable to the server (as indicated by the 
+(SH_CERT_LIST, SH_CERTIFIER_LIST and SH_SIG_LIST lists), in the form 
+of a PUBLIC_VALUE field of type PV_CERTIFICATE (see section 6.1.2).  
+If SH_ACCEPT_AUTH_PASSWORD is set to one, then CMK_SIG_CERT_DATA 
+contains an identity indicator (such as an account identifier, or, in 
+the case of doubly certified Diffie-Hellman key exchange, a 
+certificate for the Diffie-Hellman public value supplied by the 
+server in the key exchange).  Otherwise the CMK_SIG_CERT_DATA field 
+is empty, and its length is zero.
+
+If SH_ACCEPT_KEY_EXCH_SEND is set to one, and an acceptable 
+encrypted master key has not already been sent in the 
+SH_QUICK_ENCRYPTED_KEY field of the SERVER_HELLO message, then 
+CMK_PUBLIC_VALUE_DATA contains an RSA key exchange public key or 
+Diffie-Hellman/FORTEZZA KEA public value.  If 
+SH_ACCEPT_AUTH_KEY_EXCH is set to one, and no other client 
+authentication option is both acceptable to the server and preferred
+by the client, then this public value is contained in a certificate 
+acceptable to the server (as indicated by the SH_EXCH_SPECS_DATA 
+field and the SH_CERT_LIST and SH_CERTIFIER_LIST lists); otherwise, 
+the value is uncertified.  If the SH_ACCEPT_KEY_EXCH_SEND flag is set 
+to zero, or if an acceptable encrypted master key was sent in the 
+SERVER_HELLO message, then CMK_PUBLIC_VALUE_DATA is empty.  
+
+If SH_ACCEDE_KEY_EXCH_RECEIVE is set to one, and if 
+SH_PUBLIC_VALUE_DATA was not empty (indicating that the contents of 
+the CH_QUICK_ENCRYPTED_KEY field in the CLIENT_HELLO message were 
+either absent or not acceptable), then CMK_ENCRYPTED_KEY contains an 
+RSA-encrypted master key (or randomly chosen Diffie-Hellman/FORTEZZA 
+KEA public value); see section 6.1.2.  If SH_ACCEDE_KEY_EXCH_RECEIVE 
+is set to one, or if SH_PUBLIC_VALUE_DATA is empty, then 
+CMK_ENCRYPTED_KEY is empty, with length zero.
+
+If all key exchanges are completed by the sending of the 
+CLIENT_MASTER_KEY message, and if one of the SH_ACCEPT_AUTH flags is 
+set to one, then the contents of the CMK_RESPONSE field are as 
+described in section 7.2; otherwise, this field is empty, and its 
+length is zero.
+
+Upon receiving a CLIENT_MASTER_KEY message, the server verifies the
+certificates and/or authentication response, if they are required; 
+errors in any of these result in a BAD_CERTIFICATE or 
+CLIENT_AUTH_FAILED error, respectively.  If an encrypted master key 
+was sent, the server decrypts the master key for use in obtaining a 
+MAC_KEY and WRITE_KEY for each transmission direction as described in
+section 6.1.4.  The server then proceeds to the SERVER_VERIFY 
+message, if necessary, or else begins transmitting data.
+
+
+5.2.4 SERVER_VERIFY 
+
+char SV_ENCRYPTED_KEY_LENGTH[2]
+char SV_RESPONSE_LENGTH[2]
+char SV_SIG_CERT_LENGTH[4]
+char SV_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
+char SV_RESPONSE_DATA[([0] << 8)|[1]]
+char SV_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+
+The server sends this message upon receiving a valid CLIENT_MASTER_KEY
+message from the client, if not all key exchanges and authentications
+have been completed.
+
+If SH_SIG_CERT_DATA was empty, and either SH_ACCEDE_AUTH_SIG or 
+SH_ACCEDE_AUTH_PASSWORD is set to one, then the SV_SIG_CERT_DATA 
+field must not be empty.  If SH_ACCEDE_AUTH_SIG is set to one, 
+then SV_SIG_CERT_DATA must contains a certified digital signature 
+public key acceptable to the client (as indicated by the 
+(CH_SIG_LIST, CH_CERT_LIST and CH_CERTIFIER_LIST lists), in the form
+of a PUBLIC_VALUE field of type PV_CERTIFICATE (see section 6.1.2).  
+If SH_ACCEPT_AUTH_PASSWORD is set to one, then SV_SIG_CERT_DATA 
+contains an identity indicator (such as an account identifier, or, in 
+the case of doubly certified Diffie-Hellman key exchange, a 
+certificate for the Diffie-Hellman public value supplied  by the 
+server in the key exchange).  Otherwise the SV_SIG_CERT_DATA field is 
+empty, and its length is zero.
+
+If SH_ACCEPT_KEY_EXCH_SEND is set to one, and if 
+CMK_PUBLIC_VALUE_DATA was not empty (indicating that the contents of 
+the SH_QUICK_ENCRYPTED_KEY field in the SERVER_HELLO message were 
+either absent or not acceptable), then SV_ENCRYPTED_KEY contains an 
+RSA-encrypted master key (or randomly chosen Diffie-Hellman/FORTEZZA 
+KEA public value).  The format of this field is described in section
+6.1.2.  If SH_ACCEPT_KEY_EXCH_SEND is set to one, or if 
+CMK_PUBLIC_VALUE is empty, then SV_ENCRYPTED_KEY is empty, with 
+length zero.
+
+If one of the SH_ACCEPT_AUTH flags is set to one, then the contents 
+of the SV_RESPONSE field are as described in section 7.2; otherwise, 
+this field is empty, and its length is zero.
+
+Upon receiving the SERVER_VERIFY message, the client verifies the
+certificates and/or authentication response, if they are required; 
+errors in any of these result in a BAD_CERTIFICATE or 
+SERVER_AUTH_FAILED error, respectively.  If an encrypted master key 
+was sent, the client decrypts the master key for use in obtaining a 
+MAC_KEY and WRITE_KEY for each transmission direction as described 
+in section 6.1.4.  The client then proceeds to the CLIENT_VERIFY 
+message, if necessary, or else begins transmitting data.
+
+
+5.2.5 CLIENT_VERIFY 
+
+char CV_RESPONSE_LENGTH[2]
+char CV_SIG_CERT_LENGTH[4]
+char CV_RESPONSE_DATA[([0] << 8)|[1]]
+char CV_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+
+The client sends this message upon receiving a valid SERVER_VERIFY
+message from the client, if client authentication has not been 
+completed.  This message is never necessary unless 
+SH_ACCEPT_KEY_EXCH_SEND was set to one.
+
+If either SH_ACCEDE_AUTH_SIG or SH_ACCEDE_AUTH_PASSWORD is set to one, 
+then the CV_SIG_CERT_DATA  field must not be empty.  If 
+SH_ACCEDE_AUTH_SIG is set to one, then CV_SIG_CERT_DATA must contain
+a certified digital signature public key acceptable to the server (as 
+indicated by the (SH_SIG_LIST, SH_CERT_LIST and SH_CERTIFIER_LIST 
+lists), in the form of a PUBLIC_VALUE field of type PV_CERTIFICATE 
+(see section 6.1.2).  If SH_ACCEPT_AUTH_PASSWORD is set to one, then 
+CV_SIG_CERT_DATA contains an identity indicator (such as an account 
+identifier, or, in the case of doubly certified Diffie-Hellman key 
+exchange, a certificate for the Diffie-Hellman public value supplied 
+by the server in the key exchange).  Otherwise the CV_SIG_CERT_DATA 
+field is empty, and its length is zero.  The contents of the 
+CV_RESPONSE field are as described in section 7.2.
+
+Upon receiving the CLIENT_VERIFY message, the server verifies the
+certificate, if required, and the authentication response; errors in 
+either of these result in a BAD_CERTIFICATE or CLIENT_AUTH_FAILED 
+error, respectively.  The server may then begin transmitting data.
+
+
+6.  Algorithm and Certificate Types
+
+6.1  Key exchange algorithms
+
+6.1.1  Key exchange algorithm types
+
+PCT version 2 permits the following key exchange types:
+
+PCT_EXCH_RSA_PKCS1
+PCT_EXCH_RSA_PKCS1_TOKEN_DES
+PCT_EXCH_RSA_PKCS1_TOKEN_DES3
+PCT_EXCH_RSA_PKCS1_TOKEN_RC2
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4
+PCT_EXCH_DH_PKCS3
+PCT_EXCH_DH_PKCS3_TOKEN_DES
+PCT_EXCH_DH_PKCS3_TOKEN_DES3
+PCT_EXCH_FORTEZZA_TOKEN
+
+Note that the token-based key exchange types (those types whose 
+labels contain the word TOKEN) specify cipher as well (including, 
+implicitly, the FORTEZZA KEA key exchange type); if one of these is 
+chosen, then its choice of cipher overrides whatever choice of 
+cipher appears in the SH_CIPHER_SPECS_DATA field of the SERVER_HELLO 
+message.
+
+These key exchanges may use the (QUICK_)PUBLIC_VALUE field in any 
+handshake message, as well as the (QUICK_)ENCRYPTED_KEY field in the 
+subsequent handshake message.  The (first) public value sent is said 
+to be sent by (or previously obtained from) the "receiver", and the 
+second value by the "sender".  If the sender is the client, then the 
+key exchange is said to be "server-directed"; if the sender is the 
+server, then it is said to be "client-directed".
+
+
+6.1.2  Key exchange field formats
+
+The format of the (QUICK_)PUBLIC_VALUE field in any handshake 
+message in which it appears is as follows:
+
+char PV_PUBLIC_VALUE_TYPE[2]
+char PV_USER_INFO_LENGTH[4]
+char PV_PARAMETER_1_LENGTH[2]
+char PV_PARAMETER_2_LENGTH[2]
+char PV_USER_INFO_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
+char PV_PARAMETER_1_DATA[([0] << 8)|[1]]
+char PV_PARAMETER_2_DATA[([0] << 8)|[1]]
+
+There are five permissible values for PUBLIC_VALUE_TYPE.  If 
+PV_TYPE_CERTIFICATE is specified, then a certificate of a type 
+acceptable to the key exchange sender (as indicated by the 
+CH_CERT_LIST in the CLIENT_HELLO message, or the SH_CERT_LIST list, 
+in the SERVER_HELLO message, as appropriate) appears in the
+PV_USER_INFO field, and both PV_PARAMETER fields are empty, with 
+length zero.  (The PV_PARAMETER_1_LENGTH field contains the
+two-byte certificate type code identifying the type of the 
+certificate sent; this field is not, however, interpreted as the 
+length of the PV_PARAMETER_1_LENGTH field, which is still empty;
+see section 6.4.)  If PV_TYPE_PKCS_TOKEN is specified, then the 
+PV_USER_INFO field contains a PKCS-format public key of the type 
+(RSA or Diffie-Hellman) indicated by the SH_EXCH_SPECS field in the 
+SERVER_HELLO message.  If PV_TYPE_KEA is specified, then the 
+PV_USER_INFO field contains a KEA public value exactly as generated 
+by the FORTEZZA token, and both PV_PARAMETER fields are empty, with 
+length zero.  If PV_TYPE_EPHEMERAL_RSA is specified, then 
+PV_USER_INFO contains the RSA modulus from the RSA public value 
+being sent; PV_PARAMETER_1 contains the associated RSA exponent; and 
+PV_PARAMETER_2 is empty, with length zero.  If PV_TYPE_EPHEMERAL_DH 
+is specified, then PV_USER_INFO contains the actual Diffie-Hellman 
+public value; PV_PARAMETER_1 contains the generator used to 
+construct it; and PV_PARAMETER_2 contains the prime modulus used to 
+construct it.  For both EPHEMERAL public value types, the values in 
+all fields are represented with the most significant byte first, and 
+in descending order, with the least significant byte last.
+
+The (QUICK_)ENCRYPTED_KEY_DATA field in any handshake message in
+which it appears has the following format:
+
+char EK_ENCRYPTED_KEY_1_LENGTH[2]
+char EK_ENCRYPTED_KEY_2_LENGTH[2]
+char EK_ENCRYPTED_KEY_3_LENGTH[2]
+char EK_KEY_ARG_LENGTH[2]
+char EK_ENCRYPTED_KEY_1_DATA[([0] << 8)|[1]]
+char EK_ENCRYPTED_KEY_2_DATA[([0] << 8)|[1]]
+char EK_ENCRYPTED_KEY_3_DATA[([0] << 8)|[1]]
+char EK_KEY_ARG_DATA[([0] << 8)|[1]]
+
+Details of the use of these subfields is described below.
+
+
+6.1.3  Master key exchange 
+
+For the PCT_EXCH_RSA_PKCS1 key exchange type, a MASTER_KEY value is
+generated by the sender, which should be random in the following
+strong sense: attackers must not be able to predict any of the bits in
+the MASTER_KEY.  It is recommended that the bits used be either truly
+random and uniformly generated (using some random physical process) or
+else generated using a cryptographically secure pseudorandom number
+generator, which was in turn seeded with a truly random and uniformly
+generated seed.  This MASTER_KEY value is encrypted using the 
+receiver's (possibly certified) public encryption key, as obtained 
+from the (QUICK_)PUBLIC_VALUE_DATA field of some handshake message 
+(or possibly some time earlier, if the key is certified).  The 
+encryption must follow the RSA PKCS#1 standard format (see [3]), 
+block type 2.  This encryption is sent to the server in the 
+EK_ENCRYPTED_KEY_1_DATA subfield in the (QUICK_)ENCRYPTED_KEY_DATA 
+field of the handshake message following the one containing the public
+value used (or the sender's first  handshake message, if the public 
+key was obtained at an earlier time).  The encrypted key is decrypted 
+by the receiver to obtain the MASTER_KEY.  If two key exchanges of 
+this type are performed (one in each direction), then the MASTER_KEY 
+value is simply the concatenation of the two values, in the order in 
+which they were sent.  Use of the ENCRYPTED_KEY_2_DATA subfield is
+described in section 6.1.5; the ENCRYPTED_KEY_3_DATA subfield is left
+empty, with length zero.
+
+For the PCT_EXCH_DH_PKCS3 key exchange type, a random private value x
+(generated in the same way as the MASTER_KEY above) and corresponding
+public value y are generated by the sender following RSA PKCS#3
+standard format (see [4]). The value y is then sent to the receiver 
+in the EK_ENCRYPTED_KEY_1_DATA subfield of the 
+(QUICK_)ENCRYPTED_KEY_DATA field of some handshake message.  The 
+sender's private value x, along with the (possibly certified) public 
+value y' included in the (QUICK_)PUBLIC_VALUE_DATA field of the 
+previous handshake message (or possibly obtained earlier), is used to 
+generate the MASTER_KEY.  The receiver uses its private value, x', 
+along with the y value sent by the sender, to obtain the same 
+MASTER_KEY value.  If two key exchanges of this type are performed 
+(one in each direction), then the MASTER_KEY is simply the 
+concatenation of the two values, in the order in which they were sent.
+Use of the ENCRYPTED_KEY_2_DATA subfield is described in section 
+6.1.5; the ENCRYPTED_KEY_3_DATA subfield is left empty, with length 
+zero.
+
+For the various TOKEN key exchange types, an encrypted 
+CLIENT_WRITE_KEY is contained in the ENCRYPTED_KEY_1_DATA subfield, 
+and an encrypted SERVER_WRITE_KEY is contained in the 
+ENCRYPTED_KEY_2_DATA subfield of the (QUICK_)ENCRYPTED_KEY field.
+The format of the data is defined by the token implementation.  For 
+example, in the case of FORTEZZA tokens, the ENCRYPTED_KEY_1_DATA 
+subfield (like the (QUICK_)PUBLIC_VALUE field sent before it, or 
+obtained earlier), contains a KEA public value generated by the token 
+for key exchange.  The result is a CLIENT_WRITE_KEY shared by sender 
+and receiver, which is used, along with the initialization vector in
+the accompanying EK_KEY_ARG_DATA field, if needed (see section 
+6.1.5), to encrypt the SERVER_WRITE_KEY sent in the 
+ENCRYPTED_KEY_2_DATA subfield.  In all token types, this shared 
+encryption key is used to encrypt a 128-bit MASTER_KEY value for 
+MAC_KEY derivation (as described below).  This MASTER_KEY is sent in 
+the EK_ENCYRYPTED_KEY_3_DATA field of the ENCRYPTED_KEY_DATA subfield 
+accompanying the encryption key material, and uses the initialization 
+vector in the accompanying EK_KEY_ARG_DATA field, if needed (see 
+section 6.1.5).
+
+The length of the MASTER_KEY depends on the key exchange type, and on
+how many key exchanges were performed.  It is 128 bits if one RSA 
+key exchange was performed, and 256 bits if two exchanges were 
+performed and the results concatenated.  For Diffie-Hellman key
+exchange, it is the length of the receiver's public value if one key
+exchange was performed, and the sum of the lengths of each receiver's 
+public value if two key exchanges were performed.  For token-based 
+key exchange types, the MASTER_KEY (which is only relevant for MAC 
+derivation) is 128 bits long.
+
+
+6.1.4  Key derivation
+
+The CLIENT_WRITE_KEY_SEED and SERVER_WRITE_KEY_SEED are used (for 
+non-token key exchange types) to compute the CLIENT_WRITE_KEY and
+SERVER_WRITE_KEY, respectively.  They are computed as follows:
+
+CLIENT_WRITE_KEY_SEED_i = Hash( i, "cw", MASTER_KEY, "cw"^i, 
+SH_CONNECTION_ID_DATA, "cw"^i, SH_SESSION_ID_DATA,"cw"^i, 
+CH_CHALLENGE_DATA, "cw"^i )
+
+SERVER_WRITE_KEY_SEED_i = Hash( i, "svw", MASTER_KEY, "svw"^i, 
+SH_CONNECTION_ID_DATA, "svw"^i, CH_CHALLENGE_DATA, "svw"^i )
+
+The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA (see section 5.2.2).  The value of i ranges from 
+1 to m, where m is the negotiated encryption key length (the value in 
+the third byte of the SH_CIPHER_SPECS_DATA field) divided by the hash 
+output length, in bits, rounded up to the nearest integer.  This 
+resulting string is then truncated if necessary to produce a string 
+of the correct length.
+
+When a token key exchange type is used, no WRITE_KEY_SEED values are
+computed, and the client and server WRITE_KEY values are defined by 
+the specific key exchange method for the token.  For example, the 
+encryption keys exchanged in the KEA key exchange process described 
+in section 6.1.3 become the CLIENT_WRITE_KEY and SERVER_WRITE_KEY for 
+the session.
+
+The CLIENT_MAC_KEY_SEED and SERVER_MAC_KEY_SEED are always computed 
+as follows:
+
+CLIENT_MAC_KEY_SEED_i = Hash( i, MASTER_KEY, "cmac"^i, 
+SH_CONNECTION_ID_DATA, "cmac"^i, SH_SESSION_ID_DATA, "cmac"^i, 
+CH_CHALLENGE_DATA, "cmac"^i )
+
+SERVER_MAC_KEY_SEED_i = Hash( i, MASTER_KEY, "svmac"^i, 
+SH_CONNECTION_ID_DATA, "svmac"^i, CH_CHALLENGE_DATA, "svmac"^i )
+
+The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA (see section 5.2.2).  The value of i ranges from
+1 through m, where m is the negotiated MAC key length (64 plus the 
+value in the fourth byte of the SH_CIPHER_SPECS_DATA field) divided 
+by the hash output length, in bits, rounded up to the nearest integer.
+The resulting string is then truncated if necessary to produce a 
+string (CLIENT_MAC_KEY_SEED or SERVER_MAC_KEY_SEED) of the correct 
+MAC_KEY length.  This string is then padded, by repeatedly appending 
+the byte PCT_MAC_KEY_PAD_BYTE , until it is the standard key length 
+for the hash function used in MAC computation (each hash function has 
+an associated standard MAC key length; see section 6.3).  This final 
+result is the MAC_KEY (CLIENT_MAC_KEY or SERVER_MAC_KEY).
+ 
+Note that tokens which are capable of deriving keys using "keyed
+hashes", as described above, are free to use the PCT_EXCH_RSA_PKCS1
+or PCT_EXCH_DH_PKCS3 key exchange type to exchange the MASTER_KEY,
+and then to derive the rest of the keys normally.  The TOKEN key
+exchange types are for tokens that cannot do such keyed-hash key
+derivation, and can only use an exchanged key for bulk encryption
+(of, for example, the MASTER_KEY value used for MAC_KEY derivation).
+Such tokens can exchange multiple keys by using an initially 
+exchanged encryption key to encrypt other keys, as described above.
+
+Key derivation for datagram records is somewhat different from normal
+key derivation.  In a datagram record, the necessary key information 
+is contained in the DG_ENCRYPTED_KEY field at the beginning of a 
+datagram record.  Its ENCRYPTED_KEY_1_DATA subfield contains a 
+16-byte random value, which should be cryptographically random in the 
+same sense as the MASTER_KEY (see section 6.1.3).  This value is used 
+to generate the new WRITE_KEY (in the case of non-token key exchange 
+types) and the MAC_KEY for the datagram.  These are generated by 
+computing a temporary MASTER_KEY as follows:
+
+TEMP_MASTER_KEY_i = Hash( i, MASTER_KEY, "tmk"^i, 
+ENCRYPTED_KEY_1_DATA )
+
+The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA in the most recent SERVER_HELLO handshake message
+for this connection (see section 5.2.2).  The value of i ranges from
+1 through m, where m is 128 divided by the hash output length, in 
+bits, rounded up to the nearest integer.  The resulting concatenated
+string is then truncated if necessary to produce a 128-bit string.  
+The new WRITE_KEYs (in the case of non-token key exchange types) and 
+new MAC_KEYs are then computed normally, except that MASTER_KEY is 
+replaced with TEMP_MASTER_KEY.
+
+If the current keys were generated using a token-type key exchange, 
+then the DG_ENCRYPTED_KEY_2_DATA subfield contains the key information 
+necessary to decrypt the datagram, encrypted in a manner that the 
+token can decrypt.  (Note that the token type must support this type 
+of context-independent encryption of keys; otherwise, this type of key 
+management message is not permitted.)  For example, when FORTEZZA 
+tokens are used, the DG_ENCRYPTED_KEY_2_DATA subfield contains the 
+WRITE_KEY encrypted, as a key, using the current WRITE_KEY.  
+
+The DG_KEY_ARG_DATA subfield contains an arbitrary initialization 
+vector, whose use is also explained in section 6.1.5, if a block 
+cipher is being used; otherwise, the field is empty, and its length is
+zero.
+
+6.1.5  Key expansion and cipher use
+
+Every cipher has an associated standard key length (see section 6.2).
+When a non-token key exchange type has been used, and encryption keys 
+of standard length for the specified cipher have been specified in 
+the SH_CIPHER_SPECS field, then the values of CLIENT_WRITE_KEY and 
+SERVER_WRITE_KEY are simply CLIENT_WRITE_KEY_SEED and 
+SERVER_WRITE_KEY_SEED, respectively, and the ENCRYPTED_KEY_2_DATA
+subfield accompanying the encrypted master key(s) is empty.  
+Otherwise, the EK_ENCRYPTED_KEY_2_DATA subfield(s) accompanying the 
+encrypted master key(s) in the key exchange(s) contain(s) random 
+"salt" for encryption key derivation.  (The salt should be 
+cryptographically random in the same sense as the MASTER_KEY; see 
+section 6.1.3.)  If only one key exchange occurred, then the salt data
+used (which we will call CLEAR_KEY_DATA) is just the value in the 
+ENCRYPTED_KEY_2_DATA subfield accompanying the encrypted master key; 
+if two key exchanges are used, then both EK_ENCRYPTED_KEY_2_DATA 
+fields accompanying the encrypted master keys contain this random 
+data, and CLEAR_KEY_DATA is their concatenation, in the order in which 
+they were sent.  When a key length is specified which is less than the 
+standard key length for the specified cipher, then keys of the 
+specified length are derived normally as described in section 6.1.4, 
+and then "expanded" to derive standard-length keys.  The expansion 
+proceeds as follows:
+
+1.  Assign to d the result of dividing the standard key length for 
+the cipher, in bits, by the output length of the hash function, in 
+bits, rounded up to the nearest integer.
+
+2.  Divide CLEAR_KEY_DATA sequentially into d equal subsegments.
+(Note that the length of the CLEAR_KEY_DATA field must therefore be a
+multiple of d bytes, and that no two of its d equal parts, when so
+divided, may be identical.)  Denote these subsegments CLEAR_KEY_DATA_1
+through CLEAR_KEY_DATA_d.
+
+3.  Compute the d hash values
+
+WRITE_KEY_i := Hash( i, "sl"^i, WRITE_KEY_SEED, "sl"^i, 
+CLEAR_KEY_DATA_i ).
+
+The function "Hash" is the one determined by the value of
+SH_HASH_SPECS_DATA.  The WRITE_KEY_SEED is the encryption key seed 
+value (CLIENT_WRITE_KEY_SEED or SERVER_WRITE_KEY_SEED) being expanded 
+to standard length. 
+
+4.  Concatenate WRITE_KEY_1 through WRITE_LENGTH_KEY_d, and then 
+truncate as necessary to produce the WRITE_KEY which is actually used 
+for encryption.
+
+The EK_KEY_ARG_DATA subfield accompanying the (last) encrypted master 
+key contains a random eight-byte value to be used as an initialization 
+vector (IV) for the first encrypted message when a block cipher (any 
+cipher except RC4) is used.  The IV for the first block encrypted in 
+any subsequent encrypted message is simply the last encrypted block 
+of the previous message.  The EK_KEY_ARG_DATA subfield is empty when 
+cipher type PCT_CIPHER_RC4 (or key exchange type 
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4) is used.
+
+The use of a block cipher also may cause the data length to increase
+during encryption, because the ciphertext produced by block ciphers
+must always be an integer multiple of the cipher's block size.  Hence 
+when a block cipher is used, the length of the (fully or partially)
+encrypted record must be computed from the RH_RECORD_LENGTH value in 
+the record header.  ENCRYPTED_LENGTH, the length of the encrypted 
+portion of a record, is computed as the smallest multiple of the 
+cipher's block size that is at least ACTUAL_LENGTH, where 
+ACTUAL_LENGTH, the length of the encrypted data before encryption, is 
+computed as RH_RECORD_LENGTH minus the lengths of the unencrypted 
+portions of the record body (RH_RECORD_LENGTH - MAC_LENGTH - 
+DG_ENCRYPTED_KEY_LENGTH - 4 in the case of a datagram record, and 
+RH_RECORD_LENGTH - MAC_LENGTH - 2 in the case of other encrypted record 
+types).  If a block cipher is not used for encryption, then the length 
+of the encrypted data is unchanged by encryption, and the length of the 
+record body is therefore simply RH_RECORD_LENGTH.  Otherwise, the 
+length of the entire encrypted record body is ENCRYPTED_LENGTH + 
+DG_MAC_LENGTH + DG_ENCRYPTED_KEY_LENGTH + 2 in the case of datagram
+records, and ENCRYPTED_LENGTH + MAC_LENGTH for other encrypted 
+record types.
+
+
+6.2  Cipher Types
+
+PCT version 2 permits the following cipher types to be specified:
+
+PCT_CIPHER_DES
+PCT_CIPHER_IDEA
+PCT_CIPHER_RC2
+PCT_CIPHER_RC4
+PCT_CIPHER_DES_112
+PCT_CIPHER_DES_168
+
+Each of these types is denoted by a two-byte code, and is followed in
+CIPHER_SPECS_DATA fields by two one-byte length specifications, as
+described in section 5.2.1.  An encryption length specification of
+zero associated with any cipher denotes the choice of no encryption; a
+key exchange is performed in such cases solely to share keys for MAC
+computation.
+
+PCT_CIPHER_DES denotes DES (see [5]).  Its standard key length is 56
+bits.  PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 denote ciphers in
+which the input is first encrypted under DES with a first key, then
+"decrypted" under DES with a second key, then encrypted under DES with
+a third key.  For PCT_CIPHER_DES_112, the first and third keys are
+identical, and correspond to the initial 56 bits of the 112-bit
+WRITE_KEY.  The second key corresponds to the final 56 bits of the
+WRITE_KEY.  For PCT_CIPHER_DES_168, the three keys are distinct, and
+correspond to the first, second, and third 56-bit subsegments of the
+WRITE_KEY.  All three of these DES-based cipher types have 64-bit data
+blocks and are used with cipher block chaining (CBC).
+
+The standard key lengths for PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168
+are 112 bits and 168 bits, respectively.  If a key length less than
+the standard length is specified for one of these ciphers (or for
+PCT_CIPHER_DES), then the WRITE_KEY_SEED is calculated, then expanded 
+to the standard length as described above.
+
+Note that before use, each 56-bit DES key must be "adjusted" to add
+eight parity bits to form an eight-byte DES key (see [5]).  Similarly,
+if the specified WRITE_KEY length is less than its corresponding
+standard length, then each WRITE_KEY_SEED is expanded to the standard
+length using CLEAR_KEY_DATA as described above, to produce one, two,
+or three keys of 56 bits each, which are then each "adjusted" by
+adding parity bits to form an eight-byte key.
+
+PCT_CIPHER_IDEA denotes the IDEA block cipher (see [6]), with 64-bit
+data blocks and cipher block chaining.  This cipher has a standard key
+length of 128 bits.
+
+PCT_CIPHER_RC2 denotes the RC2 block cipher, with 64-bit blocks and
+cipher block chaining.  Like IDEA, this cipher has a standard key
+length of 128 bits.
+
+PCT_CIPHER_RC4 denotes the RC4 stream cipher.  Like the IDEA and RC2
+block ciphers, this cipher has a standard key length of 128 bits.
+
+6.3  Hash Types
+
+PCT version 2 permits the following hash function types to be
+specified:
+
+PCT_HASH_MD5
+PCT_HASH_MD5_TRUNC_64
+PCT_HASH_SHA
+PCT_HASH_SHA_TRUNC_80
+
+The "truncated" hash types (PCT_HASH_MD5_TRUNC_64 and 
+PCT_HASH_SHA_TRUNC_80) are identical to their non-truncated versions
+(PCT_HASH_MD5 and PCT_HASH_SHA, respectively), with the following
+exception:  when used in the second ("outer") iteration of a MAC
+or authentication response, their output is truncated to half its 
+normal length.  (Hence the resulting MAC or authentication response 
+is also only half the normal length of the hash function's output.)
+  
+PCT_HASH_MD5 denotes the MD5 hash function (see [7]), with 128-bit
+output.  (Hence PCT_HASH_MD5_TRUNC_64 has 64-bit output in the cases
+described above.)  PCT_HASH_SHA denotes the Secure Hash Algorithm 
+(see [8]), with 160-bit output.  (Hence PCT_HASH_SHA_TRUNC_80 has
+80-bit output in the cases described above.)  The standard MAC key length
+for all of the above hash functions is 512 bits.
+
+
+6.4  Certificate Types
+
+PCT version 2 permits the following certificate types to be specified:
+
+PCT_CERT_X509
+PCT_CERT_PKCS7
+PCT_CERT_PRIVATE
+
+THese types apply equally to the client's and server's certificates.
+PCT_CERT_X509 denotes a CCITT X.509 standard-conformant certificate 
+(see [10]).  PCT_CERT_PKCS7 denotes an RSA PKCS#7 standard-conformant 
+certificate (see [11]).  PCT_CERT_PRIVATE denotes a private format 
+understood by both the client and server; for instance, it may refer 
+to an account identifier using which a certificate lookup can be 
+performed on some agreed-upon certificate database.
+
+
+6.5  Signature Types
+
+PCT version 2 permits the following signature key types to be
+specified:
+
+PCT_SIG_RSA_MD5
+PCT_SIG_RSA_SHA
+PCT_SIG_DSA_SHA
+
+PCT_SIG_RSA_MD5 denotes the signature scheme consisting of hashing 
+the data to be signed using the MD5 hash algorithm, and then 
+performing an RSA private-key signature function (the inverse of RSA 
+encryption) on the result.  The signature must conform to RSA PKCS#1, 
+block type 1 (see [3]).  PCT_SIG_RSA_SHA denotes the same signature 
+scheme with SHA substituted for MD5.  PCT_SIG_DSA_SHA denotes the 
+signature scheme consisting of hashing the data to be signed using 
+the SHA hash algorithm, then computing a signature of the resulting 
+value using the Digital Signature Algorithm (DSA; see [12]).
+
+7.  Response and verification formats
+
+7.1  Prelude verification
+
+In order to guard against alteration of handshake messages before the
+master key has been exchanged (and MACs therefore made possible), a
+"prelude verification" is incorporated into every authentication 
+response.  Basically, the prelude verification is a cryptographic hash 
+of all handshake messages up to and including the one in which the 
+first authentication response is included (with the response field
+itself omitted).  
+
+Whichever message contains it, the prelude verification value is 
+computed as:
+
+VERIFY_PRELUDE_DATA = Hash( "vpd", CLIENT_HELLO, SERVER_HELLO , 
+CLIENT_MASTER_KEY, SERVER_VERIFY, CLIENT_VERIFY ) ).
+
+For the purposes of this computation, the handshake messages are 
+assumed to contain their associated message headers (i.e., their 
+HS_MSG_TYPE and HS_RECORD_FLAGS fields) and record headers.  Also, the 
+message in which the first non-empty RESPONSE_DATA field is sent is 
+assumed for this computation not to include its RESPONSE_DATA field 
+(although its correct length is included), and subsequent messages in 
+the handshake are assumed to be empty, zero-length values.
+
+The hash function used is the one specified in SH_HASH_SPECS_DATA.  
+Note that the client and server need only keep a "running hash" of all 
+the values passed in each handshake message as they appear, 
+terminating at the appropriate point to compute the value of 
+VERIFY_PRELUDE_DATA.
+
+
+7.2  Authentication responses
+
+The format of an authentication response depends on the type of 
+authentication required.  Because each type of authentication 
+response may be sent in one of several possible handshake messages
+(and by either party), the formats are described separately 
+here, and apply wherever the authentication response (RESPONSE_DATA)
+field is non-empty.
+
+In the case of key exchange-based authentication, the contents of the
+RESPONSE_DATA field are computed as follows:
+
+RESPONSE_DATA = Hash( MAC_KEY, Hash( "ke", VERIFY_PRELUDE_DATA ) ).
+
+In the case of digital signature-based authentication, the contents
+of the RESPONSE_DATA field are computed as follows: 
+
+RESPONSE_DATA = Signature( VERIFY_PRELUDE_DATA ).
+
+In the case of private "password"-based authentication, the contents
+of the RESPONSE_DATA field are computed as follows: 
+
+RESPONSE_DATA = Hash( MAC_KEY, Hash( "ppw", IDENTITY, PASSWORD, 
+VERIFY_PRELUDE_DATA ) ).
+
+Finally, in the case of authentication of a reconnection of a
+previously established session, the contents of the RESPONSE_DATA 
+field are computed as follows:
+
+RESPONSE_DATA = Hash( MAC_KEY, Hash( "recon", VERIFY_PRELUDE_DATA ) ).
+
+The computation of the VERIFY_PRELUDE_DATA value is described in 
+section 7.1.  The MAC_KEY is the CLIENT_MAC_KEY if the field is in 
+the CLIENT_MASTER_KEY or CLIENT_VERIFY message, and SERVER_MAC_KEY if 
+the field is in the SERVER_HELLO or SERVER_VERIFY message.  (The 
+origin of these MAC keys is described in section 6.1.4.)  
+The hash function choice used is determined by the 
+SH_HASH_SPECS_DATA field in this SERVER_HELLO message.  
+
+When a digital signature is used, the signature algorithm is 
+determined by the type of signature public key found in the 
+certificate passed in the SIG_CERT_DATA field accompanying the 
+RESPONSE_DATA field.  (Note that the signature algorithm may itself 
+require that a hash function be applied to the data being signed, 
+apart from the one used to compute the value in VERIFY_PRELUDE_DATA.)
+
+When a private password is used, IDENTITY is the identity of the
+client or server being authenticated (the contents of the 
+SIG_CERT_DATA field accompanying the response), and PASSWORD is the
+shared private key used in the authentication.  (Note that the same 
+shared password can in principle be used to authenticate either the 
+client to the server or vice versa, although not both simultaneously.)  
+In the case of a doubly certified Diffie-Hellman key exchange, the 
+password is simply the response sender's MAC key generated as a result 
+of the key exchange; it is considered equivalent to a password because 
+it does not change from connection to connection or from session to 
+session.
+
+
+7.3  Message Authentication Codes
+
+All PCT version 2 records which are encrypted also include a message 
+authentication code (MAC).  This value allows the receiver to verify
+that the record containing it has originated with the correct party,
+and has not been inserted or tampered with by someone else in 
+transit.
+
+The basic PCT MAC is in the form of a keyed hash of the encrypted
+data; that is, a MAC function based on a cryptographic hash function 
+is computed on the encrypted data and the sender's MAC key.  (The 
+derivation of MAC keys is described in section 6.1.)  The 
+cryptographic hash function used is determined by the code contained 
+in the SH_HASH_SPECS_DATA field in the most recent SERVER_HELLO 
+message sent during a successful handshake phase this session.  A 
+list of cryptographic hash functions permitted in PCT version 2, and 
+their associated codes and output lengths, is given in section 6.3.  
+The MAC is placed in the MAC_DATA field of the record in which it is
+found; its length (MAC_LENGTH) is the output length of the hash 
+function used.
+
+The MAC value is computed differently for datagram records and for
+other records.  In datagram records, the MAC is computed as follows:
+
+DG_MAC_DATA = Hash( MAC_KEY, Hash( RECORD_HEADER_DATA, 
+DG_ENCRYPTED_KEY_LENGTH, DG_ENCRYPTED_KEY_DATA, DG_ENCRYPTED_DATA ) )
+
+If the client is sending the record, then the MAC_KEY is the
+CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
+is the SERVER_MAC_KEY.  (The derivation of these keys is described 
+in section 6.1.)  RECORD_HEADER_DATA contains the four-byte contents 
+of the datagram record's record header, as described in section 4.2.1.  
+
+For other records containing MACs, the MAC is computed as follows:
+
+DT_MAC_DATA = Hash( MAC_KEY, Hash( DATA_TYPE, RECORD_HEADER_DATA, 
+DT_ENCRYPTED_DATA, SEQUENCE_NUMBER ) )
+
+If the client is sending the record, then the MAC_KEY is the
+CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
+is the SERVER_MAC_KEY.  (The details of the derivation of these keys
+are given in section 6.1.4.)  The value of DATA_TYPE is either the 
+empty string, or the four-byte ASCII string "pecd" if the record 
+contains pre-encrypted data (see section 4.4.1).  RECORD_HEADER_DATA 
+contains the four-byte contents of the record header described in 
+section 4.2.1.
+
+SEQUENCE_NUMBER is the value (represented in network byte order, or 
+"big endian" order) of a counter which is incremented by both the 
+sender and the receiver.  For each transmission direction, a pair 
+of counters is kept (one by the sender, one by the receiver).  
+Before the first (handshake) record is sent or received in a PCT 
+connection all sequence number counters are initialized to zero 
+(except in the case of a restarting connection with a token-based 
+exchange type, in which case the entire cipher state is preserved; 
+see section 5.2.2).  The sender's sender-to-receiver sequence 
+number is incremented after every record sent, and the receiver's 
+sender-to-receiver sequence number is incremented after every record 
+received.  (Note that this increment occurs regardless of whether or 
+not a record is, or has, a continuation record.)  Sequence number 
+counters are 32-bit unsigned quantities, and may not increment past 
+0xFFFFFFFF.  (See section 4.4.4.)
+
+MACs for pre-encrypted data can be (mostly) precomputed as well.
+The inner invocation of the hash function in the computation of 
+DT_MAC_DATA contains information that will be known at encryption 
+time, assuming non-datagram transmission and receiver support for 
+the hash function chosen by the sender for MAC calculation.  Hence, 
+the output of this inner invocation of the hash function can be 
+stored along with the pre-encrypted data, and the MAC calculated 
+efficiently at transmission time using the normal MAC_KEY, the 
+pre-calculated hash value, and the hash function used in the 
+pre-calculation.  A separate sequence number is used for MACs in 
+pre-encrypted data records until a KM_TYPE_RESUME_KEY message or 
+another KM_TYPE_FIXED_KEY message is sent and received.  This 
+sequence number begins at zero for the first data record sent and 
+received after the KM_TYPE_FIXED_KEY message, and is incremented for 
+each data record sent.  Replays of non-pre-encrypted data as 
+pre-encrypted data are prevented by the DATA_TYPE value "pecd", which
+cannot correspond to a record header prefix, in the MAC computation.
+
+In addition to the special sequence number for pre-encrypted data, 
+the normal sequence number for the same transmission direction 
+continues to increment normally as pre-encrypted data messages are 
+sent and received.  This original sequence number is returned to use,
+thus incremented, when the next key management message of type 
+KM_TYPE_RESUME_KEY or KM_TYPE_FIXED_KEY is sent and received.
+
+The receiver of an encrypted record containing a MAC uses the
+appropriate MAC_KEY and the received value of ENCRYPTED_DATA to 
+compute the correct value of MAC_DATA.  The computed MAC_DATA must 
+agree bit for bit with the transmitted MAC_DATA.  If the two are not 
+identical, then an INTEGRITY_CHECK_FAILED error occurs, and it is 
+recommended that the record be treated as though it had not been 
+received.  (See section 4.6.)
+
+
+8.  Constants
+
+Following is a list of constant values used in the PCT protocol
+version 1.
+
+8.1  Record and message type codes
+
+These codes are each placed in the record or message type fields of
+PCT records and messages.
+
+RT_HANDSHAKE                :=  0x0301
+RT_KEY_MGMT                 :=  0x0302
+RT_DATAGRAM                 :=  0x0303
+RT_ERROR                    :=  0x0304
+RT_USER_DATA                :=  0x0305
+RT_PCT_VERSION_1_CH         :=  0x0180
+RT_PCT_VERSION_1_SH         :=  0x0280
+RT_SSL_VERSION_2_CH         :=  0x0100
+RT_SSL_VERSION_3_CH         :=  0x00**
+RT_CD_RESERVED              :=  0x6364
+RT_KR_RESERVED              :=  0x6B72
+RT_ESCROW                   :=  0x0310
+
+HS_CLIENT_HELLO                 :=      0x0000
+HS_SERVER_HELLO                 :=      0x0001
+HS_CLIENT_MASTER_KEY            :=      0x0002
+HS_SERVER_VERIFY                :=      0x0003
+HS_CLIENT_VERIFY                :=      0x0004
+
+KM_TYPE_FIXED_KEY       :=  0x0001
+KM_TYPE_RESUME_KEY      :=  0x0002
+KM_TYPE_REDO_HANDSHAKE  :=  0x0003
+KM_TYPE_CLOSE_CONN      :=  0x0004
+
+DM_TYPE_USER_DATA       :=  0x0000
+
+PV_TYPE_CERTIFICATE     :=  0x0001
+PV_TYPE_PKCS_TOKEN      :=  0x0002
+PV_TYPE_KEA             :=  0x0003
+PV_TYPE_EPHEMERAL_RSA   :=  0x0004
+PV_TYPE_EPHEMERAL_DH    :=  0x0005
+
+EW_TYPE_MASTER_KEY      :=  0x0001
+EW_TYPE_WRITE_KEYS      :=  0x0002
+
+8.2  Specification Type Codes
+
+These are codes used to specify types of cipher, key exchange, hash
+function, certificate, and digital signature in the protocol.
+
+PCT_EXCH_RSA_PKCS1              :=      0x0001
+PCT_EXCH_RSA_PKCS1_TOKEN_DES    :=      0x0002
+PCT_EXCH_RSA_PKCS1_TOKEN_DES3   :=      0x0003
+PCT_EXCH_RSA_PKCS1_TOKEN_RC2    :=      0x0004
+PCT_EXCH_RSA_PKCS1_TOKEN_RC4    :=      0x0005
+PCT_EXCH_DH_PKCS3               :=      0x0006
+PCT_EXCH_DH_PKCS3_TOKEN_DES     :=      0x0007
+PCT_EXCH_DH_PKCS3_TOKEN_DES3    :=      0x0008
+PCT_EXCH_FORTEZZA_TOKEN         :=      0x0009
+
+PCT_CIPHER_DES          :=      0x0001
+PCT_CIPHER_IDEA         :=      0x0002
+PCT_CIPHER_RC2          :=      0x0003
+PCT_CIPHER_RC4          :=      0x0004
+PCT_CIPHER_DES_112      :=      0x0005
+PCT_CIPHER_DES_168      :=      0x0006
+
+PCT_HASH_MD5            :=      0x0001
+PCT_HASH_MD5_TRUNC_64   :=      0x0002
+PCT_HASH_SHA            :=      0x0003
+PCT_HASH_SHA_TRUNC_80   :=      0x0004
+PCT_HASH_DES_DM         :=      0x0005
+
+PCT_CERT_NONE           :=      0x0000
+PCT_CERT_X509           :=      0x0001
+PCT_CERT_PKCS7          :=      0x0002
+PCT_CERT_PRIVATE    	:=	  0x0003
+
+PCT_SIG_NONE            :=      0x0000
+PCT_SIG_RSA_MD5         :=      0x0001
+PCT_SIG_RSA_SHA         :=      0x0002
+PCT_SIG_DSA_SHA         :=      0x0003
+
+8.3  Error Codes
+
+These codes are used to identify errors, when they occur, in error
+messages.
+
+PCT_ERR_BAD_CERTIFICATE         :=      0x0001
+PCT_ERR_CLIENT_AUTH_FAILED      :=      0x0002
+PCT_ERR_ILLEGAL_MESSAGE         :=      0x0003
+PCT_ERR_INTEGRITY_CHECK_FAILED  :=      0x0004
+PCT_ERR_SERVER_AUTH_FAILED      :=      0x0005
+PCT_ERR_SPECS_MISMATCH          :=      0x0006
+PCT_ERR_CONN_BROKEN		  :=	    0x0007
+
+8.4  Miscellaneous Codes
+
+These include PCT version 1 escape type codes, version numbers, 
+and assorted constants associated with the PCT protocol.
+
+PCT_VERSION_V2                  :=      0x0002
+
+PCT_SESSION_ID_NONE             :=      0x00 (32 bytes of zeros)
+PCT_MAC_KEY_PAD_BYTE		  :=	    0x36
+
+PCT_ET_OOB_DATA                 :=      0x01
+PCT_ET_REDO_CONN                :=      0x02
+
+PCT_CH_OFFSET_V1                :=      0x000A
+PCT_CH_OFFSET_V2                :=      0x0018
+
+PCT_MAX_RECORD_LENGTH_2_BYTE_HEADER :=  32767
+PCT_MAX_RECORD_LENGTH_3_BYTE_HEADER :=  16383
+PCT_MAX_RECORD_LENGTH_V2            :=  32763
+
+
+9.  PCT version 1 compatibility
+
+PCT version 1 is a subset of PCT version 2; however, because of 
+differing formats, connections are identified as either using version
+1 or version 2.  The identification occurs during the handshake phase;
+a value of RT_PCT_VERSION_1_CH in the RH_RECORD_TYPE field of a
+record header indicates a PCT version 1 CLIENT_HELLO message, and a 
+value of RT_PCT_VERSION_1_SH in the RH_RECORD_TYPE field of a
+record header indicates a PCT version 1 SERVER_HELLO message.  If
+the former is the first record received in a connection, it signals
+to the receiver that it is expected to be a server in a PCT version
+1 connection.  The client and server then follow the PCT version 1 
+protocol for the remainder of the connection.  If the latter is the
+response received to a PCT version 2 CLIENT_HELLO message, it signals
+to the receiver that it is expected to be a client in a PCT version 1
+type connection.  The client and server then follow the PCT version
+1 protocol for the remainder of the connection.  The PCT version 1 
+protocol is specified in [2].
+
+Note that a PCT version 1 server implementation that correctly uses
+the CH_OFFSET field to determine the location of the data fields in
+the CLIENT_HELLO message can successfully interpret a PCT version 2
+CLIENT_HELLO message, and reply with a PCT version 1 SERVER_HELLO
+message.  However, reconnections in a continued session must maintain 
+the same version as the first connection for the session.
+
+Note also that a PCT version 1 record header may have a three-byte
+record length field; this format can always be recognized by a first 
+(most significant) bit of zero in the RH_RECORD_LENGTH field.
+
+
+10. Security Considerations
+
+This entire document is about security.
+
+
+References
+
+[1]  K. Hickman and T. Elgamal.  The SSL Protocol.  Internet-draft,
+June 1995.
+
+[2]  J. Benaloh, B. Lampson, D. Simon, T. Spies and B. Yee.  The 
+PCT Protocol.  Internet Draft, October 1995.
+
+[3]  RSA Laboratories, "PKCS #1: RSA Encryption Standard", Version
+1.5, November 1993.
+
+[4]  RSA Laboratories, "PKCS #3: "Diffie-Hellman Key-Agreement
+Standard", Version 1.4, November 1993.
+
+[5]  NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
+Standards, US Department of Commerce, Jan. 1977.
+
+[6]  X. Lai, "On the Design and Security of Block Ciphers", ETH Series
+in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
+
+[7]  R. Rivest, RFC 1321: "The MD5 Message Digest Algorithm", April
+1992.
+
+[8]  NIST FIPS PUB 180-1, "Secure Hash Standard", National Institute
+of Standards and Technology, US Department of Commerce, Apr. 1995.
+
+[9]  ISO/IEC 9797, "Data Cryptographic Techniques--Data Integrity
+Mechanism Using a Cryptographic Check Function Employing a Block
+Cipher Algorithm", 1989.
+
+[10]  CCITT. Recommendation X.509: "The Directory - Authentication
+Framework". 1988.
+
+[11]  RSA Laboratories, "PKCS #7: Cryptographic Message Syntax
+Standard", Version 1.5, November 1993.
+
+[12]  NIST FIPS PUB 186, "Digital Signature Standard", National
+Institute of Standards and Technology, US Department of Commerce, May
+1994.
+
+[13]  B. Schneier, "Applied Cryptography: Protocols, Algorithms, and
+Source Code in C", John Wiley & Sons, Inc., 1994.
+
+[14]  R.L. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining
+Digital Signatures and Public Key Cryptosystems", MIT Laboratory for
+Computer Science and Department of Mathematics, S.L. Graham,
+R.L. Rivest ed. Communications of the ACM, February 1978 (Vol 21,
+No. 2) pp. 120-126.
+
+[15]  W. Diffie and M.E. Hellman, "New directions in Cryptography",
+IEEE Transactions on Information Theory, November 1976 (Vol. IT-22, 
+No. 6) pp. 644-654.
+
+
+Appendix A:  Escrow Support
+
+To facilitate the escrow of keys used in PCT connections (across 
+firewalls, for instance), we describe here a protocol which can be 
+used to encapsulate PCT records, passing the encryption keys for 
+the connection to a third party.  The protocol involves a distinct 
+escrow record type (RT_ESCROW).  An escrow record header has the 
+normal format, although all flags must always be set to zero.  The 
+record itself has the following format:
+
+char EW_ESCROW_TYPE[2]
+char EW_KEY_ID[16]
+char EW_KEY_1_LENGTH[2]
+char EW_KEY_2_LENGTH[2]
+char EW_KEY_1_DATA[([0] << 8)|[1]]
+char EW_KEY_2_DATA[([0] << 8)|[1]]
+char EW_ENCLOSED_RECORD_DATA[DATA_LENGTH]
+
+The two defined escrow record types are EW_TYPE_MASTER_KEY and
+EW_TYPE_WRITE_KEYS.  In the first type, EW_KEY_1_DATA contains the
+MASTER_KEY for this session, and EW_KEY_2_DATA is empty, with length
+zero.  In the second type, EW_KEY_1_DATA contains the sender's
+WRITE_KEY, and EW_KEY_2_DATA contains the non-sender's WRITE_KEY.
+These keys are encrypted using a key and format determined by the
+EW_KEY_ID field, which contains a 16-byte identifier for the key 
+used in the encryption.  The format of the encryption, and the key
+distribution method used, are left to the implementation's discretion.
+(For example, a PCT connection between sender and escrower can be used
+to exchange a symmetric key and associated identifier; alternatively,
+a fixed key-exchange RSA public key can be designated as the escrow
+key to be used.)  ENCLOSED_RECORD_DATA holds a normal PCT record, 
+whose length can be calculated from the escrow record's header and the
+lengths of the other fields in the escrow record.  (Note that the 
+normal length limit for an escrow record thus imposes a 
+shorter-than-normal limit on the size of the encapsulated record.)
+
+In a normal connection, the first record sent after all key exchanges
+in the handshake have completed might be encapsulated in an escrow 
+record; the key(s) so escrowed would be in effect until the next 
+escrow encapsulation.  For example, in a connection between a client
+and server each operating "behind" a firewall, the client and server
+would each encapsulate their last handshake message (or first data
+message) in an escrow record, and pass it to the firewall.  Each
+firewall would receive the encapsulated record, decrypt the 
+escrowed key(s), then pass the enclosed record through itself 
+unaltered.  Thereafter, each firewall would be able to read all 
+messages passing in each direction, until a change of key occurred 
+(prompted by, say, a key management message, which would presumably 
+have to be enclosed in another escrow record).
+
+The type of escrow used depends on the level of trust between client
+or server and escrower.  If a master key is escrowed, then the 
+escrower is capable of not only decrypting but also altering messages,
+recalculating MACs accordingly.  On the other hand, if only the
+encryption keys are escrowed, then the escrower is incapable not 
+only of altering messages, but also of verifying MACs (to determine, 
+for instance, if the correct encryption key was supplied).  
+Furthermore, since the shared master key is used to derive independent
+keys for datagram messages, escrow of only encryption keys makes
+incoming datagram traffic unreadable to the escrower.
+
+
+
+Patent Statement
+
+This version of the PCT 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.
+
+See existing RFCs, including RFC 1170, that discuss known public key
+cryptography patents and licensing terms and conditions.
+
+The Internet Society, Internet Architecture Board, Internet
+Engineering Steering Group and the Corporation for National 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 user's own responsibility.
+
+Author's Address
+
+Daniel R. Simon
+Microsoft Corp.
+One Microsoft Way
+Redmond WA 98052
+USA
+
+pct@microsoft.com
+
+This Internet-Draft expires 10 October 1996.
+
+
diff --git a/doc/protocol/draft-hickman-netscape-ssl-00.txt b/doc/protocol/draft-hickman-netscape-ssl-00.txt
new file mode 100644
index 0000000000..5658bdff89
--- /dev/null
+++ b/doc/protocol/draft-hickman-netscape-ssl-00.txt
@@ -0,0 +1,1510 @@
+
+						 Kipp E.B. Hickman
+Internet Draft	   		          Netscape Communications Corp
+					    April 1995 (Expires 10/95)
+
+                           The SSL Protocol
+                    <draft-hickman-netscape-ssl-00.txt>
+
+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 obsoleted 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 the Secure Sockets Layer (SSL) protocol, a 
+security protocol that provides privacy over the Internet. The protocol 
+allows client/server applications to communicate in a way that cannot be 
+eavesdropped. Server's are always authenticated and clients are optionally 
+authenticated.
+
+3. INTRODUCTION
+
+The SSL Protocol is designed to provide privacy between two 
+communicating applications (a client and a server). Second, the protocol is 
+designed to authenticate the server, and optionally the client. SSL requires 
+a reliable transport protocol (e.g. TCP) for data transmission and 
+reception.
+
+The advantage of the SSL Protocol is that it is application protocol 
+independent. A "higher level" application protocol (e.g. HTTP, FTP, 
+TELNET, etc.) can layer on top of the SSL Protocol transparently. The 
+SSL Protocol can negotiate an encryption algorithm and session key as 
+well as authenticate a server before the application protocol transmits or 
+receives its first byte of data. All of the application protocol data is 
+transmitted encrypted, ensuring privacy.
+
+The SSL protocol provides "channel security" which has three basic 
+properties:
+
+  The channel is private. Encryption is used for all messages after a 
+simple handshake is used to define a secret key. Symmetric 
+cryptography is used for data encryption (e.g. DES, RC4, etc.)
+
+  The channel is authenticated. The server endpoint of the conversation 
+is always authenticated, while the client endpoint is optionally 
+authenticated. Asymmetric cryptography is used for authentication 
+
+Hickman							[page  1]
+
+(e.g. Public Key Cryptography).
+
+  The channel is reliable. The message transport includes a message 
+integrity check (using a MAC). Secure hash functions (e.g. MD2, 
+MD5) are used for MAC computations.
+
+The SSL protocol is actually composed of two protocols. At the lowest 
+level, layered on top of some reliable transport protocol, is the "SSL 
+Record Protocol". The SSL Record Protocol is used for encapsulation of 
+all transmitted and received data, including the SSL Handshake Protocol, 
+which is used to establish security parameters.
+4. SSL Record Protocol Specification
+
+4.1 SSL Record Header Format
+
+In SSL, all data sent is encapsulated in a record, an object which is 
+composed of a header and some non-zero amount of data. Each record 
+header contains a two or three byte length code. If the most significant bit 
+is set in the first byte of the record length code then the record has no 
+padding and the total header length will be 2 bytes, otherwise the record 
+has padding and the total header length will be 3 bytes. The record header 
+is transmitted before the data portion of the record.
+
+Note that in the long header case (3 bytes total), the second most 
+significant bit in the first byte has special meaning. When zero, the record 
+being sent is a data record. When one, the record being sent is a security 
+escape (there are currently no examples of security escapes; this is 
+reserved for future versions of the protocol). In either case, the length code 
+describes how much data is in the record.
+
+The record length code does not include the number of bytes consumed by 
+the record header (2 or 3). For the 2 byte header, the record length is 
+computed by (using a "C"-like notation):
+
+RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
+
+Where byte[0] represents the first byte received and byte[1] the second 
+byte received. When the 3 byte header is used, the record length is 
+computed as follows (using a "C"-like notation):
+
+RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
+IS-ESCAPE = (byte[0] & 0x40) != 0;
+PADDING = byte[2];
+
+The record header defines a value called PADDING. The PADDING 
+value specifies how many bytes of data were appended to the original 
+record by the sender. The padding data is used to make the record length 
+be a multiple of the block ciphers block size when a block cipher is used 
+for encryption.
+
+The sender of a "padded" record appends the padding data to the end of its 
+normal data and then encrypts the total amount (which is now a multiple 
+of the block cipher's block size). The actual value of the padding data is 
+unimportant, but the encrypted form of it must be transmitted for the 
+receiver to properly decrypt the record. Once the total amount being 
+
+Hickman							[page  2]
+
+transmitted is known the header can be properly constructed with the 
+PADDING value set appropriately.
+
+The receiver of a padded record decrypts the entire record data (sans 
+record length and the optional padding) to get the clear data, then subtracts 
+the PADDING value from the RECORD-LENGTH to determine the 
+final RECORD-LENGTH. The clear form of the padding data must be 
+discarded.
+
+4.1.1 SSL Record Data Format
+
+The data portion of an SSL record is composed of three components 
+(transmitted and received in the order shown):
+
+MAC-DATA[MAC-SIZE]
+ACTUAL-DATA[N]
+PADDING-DATA[PADDING]
+
+ACTUAL-DATA is the actual data being transmitted (the message 
+payload). PADDING-DATA is the padding data sent when a block cipher 
+is used and padding is needed. Finally, MAC-DATA is the "Message 
+Authentication Code".
+
+When SSL records are sent in the clear, no cipher is used.Consequently the 
+amount of PADDING-DATA will be zero and the amount of MAC-
+DATA will be zero. When encryption is in effect, the PADDING-DATA 
+will be a function of the cipher block size. The MAC-DATA is a function 
+of the CIPHER-CHOICE (more about that later).
+
+The MAC-DATA is computed as follows:
+
+MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA,
+SEQUENCE-NUMBER ]
+
+Where the SECRET data is fed to the hash function first, followed by the 
+ACTUAL-DATA, which is followed by the PADDING-DATA which is 
+finally followed by the SEQUENCE-NUMBER. The SEQUENCE-
+NUMBER is a 32 bit value which is presented to the hash function as four 
+bytes, with the first byte being the most significant byte of the sequence 
+number, the second byte being the next most significant byte of the 
+sequence number, the third byte being the third most significant byte, and 
+the fourth byte being the least significant byte (that is, in network byte 
+order or "big endian" order).
+
+MAC-SIZE is a function of the digest algorithm being used. For MD2 and 
+MD5 the MAC-SIZE will be 16 bytes (128 bits).
+
+The SECRET value is a function of which party is sending the message. If 
+the client is sending the message then the SECRET is the CLIENT-
+WRITE-KEY (the server will use the SERVER-READ-KEY to verify 
+the MAC). If the client is receiving the message then the SECRET is the 
+CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY 
+to
+generate the MAC).
+
+Hickman							[page  3]
+
+The SEQUENCE-NUMBER is a counter which is incremented by both 
+the sender and the receiver. For each transmission direction, a pair of 
+counters is kept (one by the sender, one by the receiver). Every time a 
+message is sent by a sender the counter is incremented. Sequence numbers 
+are 32 bit unsigned quantities and must wrap to zero after incrementing 
+past 0xFFFFFFFF.
+
+The receiver of a message uses the expected value of the sequence number 
+as input into the MAC HASH function (the HASH function is chosen from 
+the CIPHER-CHOICE). The computed MAC-DATA must agree bit for 
+bit with the transmitted MAC-DATA. If the comparison is not identity 
+then the record is considered damaged, and it is to be treated as if an "I/O 
+Error" had occurred (i.e. an unrecoverable error is asserted and the 
+connection is closed).
+
+A final consistency check is done when a block cipher is used and the 
+protocol is using encryption. The amount of data present in a record 
+(RECORD-LENGTH))must be a multiple of the cipher's block size. If 
+the received record is not a multiple of the cipher's block size then the 
+record is considered damaged, and it is to be treated as if an "I/O Error" 
+had occurred (i.e. an unrecoverable error is asserted and the connection is 
+closed).
+
+The SSL Record Layer is used for all SSL communications, including 
+handshake messages, security escapes and application data transfers. The 
+SSL Record Layer is used by both the client and the server at all times.
+
+For a two byte header, the maximum record length is 32767 bytes. For the 
+three byte header, the maximum record length is 16383 bytes. The SSL 
+Handshake Protocol messages are constrained to fit in a single SSL Record 
+Protocol record. Application protocol messages are allowed to consume 
+multiple SSL Record Protocol record's.
+
+Before the first record is sent using SSL all sequence numbers are 
+initialized to zero. The transmit sequence number is incremented after 
+every message sent, starting with the CLIENT-HELLO and SERVER-
+HELLO messages.
+
+5. SSL Handshake Protocol Specification
+
+5.1 SSL Handshake Protocol Flow
+
+The SSL Handshake Protocol is used to negotiate security enhancements 
+to data sent using the SSL Record Protocol. The security enhancements 
+consist of authentication, symmetric encryption, and message integrity.
+
+The SSL Handshake Protocol has two major phases. The first phase is 
+used to establish private communications. The second phase is used for 
+client authentication.
+
+5.1.1 Phase 1
+
+The first phase is the initial connection phase where both parties 
+communicate their "hello" messages. The client initiates the conversation 
+by sending the CLIENT-HELLO message. The server receives the 
+
+Hickman							[page  4]
+
+CLIENT-HELLO message and processes it responding with the 
+SERVER-HELLO message.
+
+At this point both the client and server have enough information to know 
+whether or not a new "master key" is needed (The master key is used for 
+production of the symmetric encryption session keys). When a new master 
+key is not needed, both the client and the server proceed immediately to 
+phase 2.
+
+When a new master key is needed, the SERVER-HELLO message will 
+contain enough information for the client to generate it. This includes the 
+server's signed certificate (more about that later), a list of bulk cipher 
+specifications (see below), and a connection-id (a connection-id is a 
+randomly generated value generated by the server that is used by the client 
+and server during a single connection). The client generates the master key 
+and responds with a CLIENT-MASTER-KEY message (or an ERROR 
+message if the server information indicates that the client and server 
+cannot agree on a bulk cipher).
+
+It should be noted here that each SSL endpoint uses a pair of ciphers per 
+connection (for a total of four ciphers). At each endpoint, one cipher is 
+used for outgoing communications, and one is used for incoming 
+communications. When the client or server generate a session key, they 
+actually generate two keys, the SERVER-READ-KEY (also known as the 
+CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known 
+as the CLIENT-READ-KEY). The master key is used by the client and 
+server to generate the various session keys (more about that later).
+
+Finally, the server sends a SERVER-VERIFY message to the client after 
+the master key has been determined. This final step authenticates the 
+server, because only a server which has the appropriate public key can 
+know the master key.
+
+5.1.2 Phase 2
+
+The second phase is the client authentication phase. The server has already 
+been authenticated by the client in the first phase, so this phase is primarily 
+used to authenticate the client. In a typical scenario, the server will require 
+authentication of  the client and send a REQUEST-CERTIFICATE 
+message. The client will answer in the positive if it has the needed 
+information, or send an ERROR message if it does not. This protocol 
+specification does not define the semantics of an ERROR response to a 
+server request (e.g., an implementation can ignore the error, close the 
+connection, etc. and still conform to this specification). In addition, it is 
+permissable for a server to cache client authentication information with the 
+"session-id" cache. The server is not required to re-authenticate the client 
+on every connection.
+
+When a party is done authenticating the other party, it sends its finished 
+message. For the client, the CLIENT-FINISHED message contains the 
+encrypted form of the CONNECTION-ID for the server to verify. If the 
+verification fails, the server sends an ERROR message.
+
+Once a party has sent its finished message it must continue to listen to its 
+peers messages until it too receives a finished message. Once a party has 
+
+Hickman							[page  5]
+
+both sent a finished message and received its peers finished message, the 
+SSL handshake protocol is done. At this point the application protocol 
+begins to operate (Note: the application protocol continues to be layered 
+on the SSL Record Protocol).
+
+5.2 Typical Protocol Message Flow
+
+The following sequences define several typical protocol message flows for 
+the SSL Handshake Protocol. In these examples we have two principals in 
+the conversation: the client and the server. We use a notation commonly 
+found in the literature [10]. When something is enclosed in curly braces 
+"{something}key" then the something has been encrypted using "key".
+
+5.2.1 Assuming no session-identifier
+
+client-hello		C -> S: challenge, cipher_specs
+server-hello		S -> C: connection-id, server_certificate,
+				  cipher_specs
+client-master-key	C -> S: {master_key}server_public_key
+client-finish		C -> S: {connection-id}client_write_key
+server-verify		S -> C: {challenge}server_write_key
+server-finish		S -> C: {new_session_id}server_write_key
+
+5.2.2 Assuming a session-identifier was found by both client & server
+
+client-hello		C -> S: challenge, session_id, cipher_specs
+server-hello		S -> C: connection-id, session_id_hit
+client-finish		C -> S: {connection-id}client_write_key
+server-verify		S -> C: {challenge}server_write_key
+server-finish		S -> C: {session_id}server_write_key
+
+5.2.3 Assuming a session-identifier was used and client authentication 
+is used
+
+client-hello		C -> S: challenge, session_id, cipher_specs
+server-hello		S -> C: connection-id, session_id_hit
+client-finish		C -> S: {connection-id}client_write_key
+server-verify		S -> C: {challenge}server_write_key
+request-certificate	S -> C: {auth_type,challenge'}
+				  server_write_key
+client-certificate	C -> S: {cert_type,client_cert,
+				   response_data}client_write_key
+server-finish		S -> C: {session_id}server_write_key
+
+In this last exchange, the response_data is a function of the auth_type.
+
+5.3 Errors
+
+Error handling in the SSL connection protocol is very simple. When an 
+error is detected, the detecting party sends a message to the other party. 
+Errors that are not recoverable cause the client and server to abort the 
+secure connection. Servers and client are required to "forget" any session-
+identifiers associated with a failing connection.
+
+The SSL Handshake Protocol defines the following errors:
+
+
+Hickman							[page  6]
+
+NO-CIPHER-ERROR
+This error is returned by the client to the server when it cannot find 
+a cipher or key size that it supports that is also supported by the 
+server. This error is not recoverable.
+
+NO-CERTIFICATE-ERROR
+When a REQUEST-CERTIFICATE message is sent, this error may 
+be returned if the client has no certificate to reply with. This error 
+is recoverable (for client authentication only).
+
+BAD-CERTIFICATE-ERROR
+This error is returned when a certificate is deemed bad by the 
+receiving party. Bad means that either the signature of the 
+certificate was bad or that the values in the certificate were 
+inappropriate (e.g. a name in the certificate did not match the 
+expected name). This error is recoverable (for client authentication 
+only).
+
+UNSUPPORTED-CERTIFICATE-TYPE-ERROR
+This error is returned when a client/server receives a certificate 
+type that it can't support. This error is recoverable (for client 
+authentication only).
+
+5.4 SSL Handshake Protocol Messages
+
+The SSL Handshake Protocol messages are encapsulated using the SSL 
+Record Protocol and are composed of two parts: a single byte message 
+type code, and some data. The client and server exchange messages until 
+both ends have sent their "finished" message, indicating that they are 
+satisfied with the SSL Handshake Protocol conversation. While one end 
+may be finished, the other may not, therefore the finished end must 
+continue to receive SSL Handshake Protocol messages until it receives a 
+"finished" message from its peer.
+
+After the pair of session keys has been determined by each party, the 
+message bodies are encrypted. For the client, this happens after it verifies 
+the session-identifier or creates a new master key and has sent it to the 
+server. For the server, this happens after the session-identifier is found to 
+be good, or the server receives the client's master key message.
+
+The following notation is used for SSLHP messages:
+
+char MSG-EXAMPLE
+char FIELD1
+char FIELD2
+char THING-MSB
+char THING-LSB
+char THING-DATA[(MSB<<8)|LSB];
+...
+
+This notation defines the data in the protocol message, including the 
+message type code. The order is presented top to bottom, with the top most 
+element being transmitted first, and the bottom most element transferred 
+last.
+
+
+Hickman							[page  7]
+
+For the "THING-DATA" entry, the MSB and LSB values are actually 
+THING-MSB and THING-LSB (respectively) and define the number of 
+bytes of data actually present in the message. For example, if THING-
+MSB were zero and THING-LSB were 8 then the THING-DATA array 
+would be exactly 8 bytes long. This shorthand is used below.
+
+Length codes are unsigned values, and when the MSB and LSB are 
+combined the result is an unsigned value. Unless otherwise specified 
+lengths values are "length in bytes".
+
+5.5 Client Only Protocol Messages
+
+There are several messages that are only generated by clients. These 
+messages are never generated by correctly functioning servers. A client 
+receiving such a message closes the connection to the server and returns an 
+error status to the application through some unspecified mechanism.
+
+5.5.1 CLIENT-HELLO (Phase 1; Sent in the clear)
+
+char MSG-CLIENT-HELLO
+char CLIENT-VERSION-MSB
+char CLIENT-VERSION-LSB
+char CIPHER-SPECS-LENGTH-MSB
+char CIPHER-SPECS-LENGTH-LSB
+char SESSION-ID-LENGTH-MSB
+char SESSION-ID-LENGTH-LSB
+char CHALLENGE-LENGTH-MSB
+char CHALLENGE-LENGTH-LSB
+char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
+char SESSION-ID-DATA[(MSB<<8)|LSB]
+char CHALLENGE-DATA[(MSB<<8)|LSB]
+
+When a client first connects to a server it is required to send the CLIENT-
+HELLO message. The server is expecting this message from the client as 
+its first message. It is an error for a client to send anything else as its
+first 
+message.
+
+The client sends to the server its SSL version, its cipher specs (see below), 
+some challenge data, and the session-identifier data. The session-identifier 
+data is only sent if the client found a session-identifier in its cache for the 
+server, and the SESSION-ID-LENGTH will be non-zero. When there is 
+no session-identifier for the server SESSION-ID-LENGTH must be zero. 
+The challenge data is used to authenticate the server. After the client and 
+server agree on a pair of session keys, the server returns a SERVER-
+VERIFY message with the encrypted form of the CHALLENGE-DATA.
+
+Also note that the server will not send its SERVER-HELLO message 
+until it has received the CLIENT-HELLO message. This is done so that 
+the server can indicate the status of the client's session-identifier back to 
+the client in the server's first message (i.e. to increase protocol efficiency 
+and reduce the number of round trips required).
+
+The server examines the CLIENT-HELLO message and will verify that it 
+can support the client version and one of the client cipher specs. The 
+server can optionally edit the cipher specs, removing any entries it doesn't 
+
+Hickman							[page  8]
+
+choose to support. The edited version will be returned in the SERVER-
+HELLO message if the session-identifier is not in the server's cache.
+
+The CIPHER-SPECS-LENGTH must be greater than zero and a 
+multiple of 3. The SESSION-ID-LENGTH must either be zero or 16. 
+The CHALLENGE-LENGTH must be greater than or equal to 16 and 
+less than or equal to 32.
+
+This message must be the first message sent by the client to the server. 
+After the message is sent the client waits for a SERVER-HELLO 
+message. Any other message returned by the server (other than ERROR) 
+is disallowed.
+
+5.5.2 CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)
+
+char MSG-CLIENT-MASTER-KEY
+char CIPHER-KIND[3]
+char CLEAR-KEY-LENGTH-MSB
+char CLEAR-KEY-LENGTH-LSB
+char ENCRYPTED-KEY-LENGTH-MSB
+char ENCRYPTED-KEY-LENGTH-LSB
+char KEY-ARG-LENGTH-MSB
+char KEY-ARG-LENGTH-LSB
+char CLEAR-KEY-DATA[MSB<<8|LSB]
+char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
+char KEY-ARG-DATA[MSB<<8|LSB]
+
+The client sends this message when it has determined a master key for the 
+server to use. Note that when a session-identifier has been agreed upon, 
+this message is not sent.
+
+The CIPHER-KIND field indicates which cipher was chosen from the 
+server's CIPHER-SPECS.
+
+The CLEAR-KEY-DATA contains the clear portion of the MASTER-
+KEY. The CLEAR-KEY-DATA is combined with the SECRET-KEY-
+DATA (described shortly) to form the MASTER-KEY, with the 
+SECRET-KEY-DATA being the least significant bytes of the final 
+MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret 
+portions of the MASTER-KEY, encrypted using the server's public key. 
+The encryption block is formatted using block type 2 from PKCS#1 [5]. 
+The data portion of the block is formatted as follows:
+
+char SECRET-KEY-DATA[SECRET-LENGTH]
+
+SECRET-LENGTH is the number of bytes of each session key that is 
+being transmitted encrypted. The SECRET-LENGTH plus the CLEAR-
+KEY-LENGTH equals the number of bytes present in the cipher key (as 
+defined by the CIPHER-KIND). It is an error if the SECRET-LENGTH 
+found after decrypting the PKCS#1 formatted encryption block doesn't 
+match the expected value. It is also an error if CLEAR-KEY-LENGTH is 
+non-zero and the CIPHER-KIND is not an export cipher.
+
+If the key algorithm needs an argument (for example, DES-CBC's 
+initialization vector) then the KEY-ARG-LENGTH fields will be non-
+
+Hickman							[page 9]
+
+zero and the KEY-ARG-DATA will contain the relevant data. For the 
+SSL_CK_RC2_128_CBC_WITH_MD5, 
+SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, 
+SSL_CK_IDEA_128_CBC_WITH_MD5, 
+SSL_CK_DES_64_CBC_WITH_MD5 and 
+SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG 
+data must be present and be exactly 8 bytes long.
+
+Client and server session key production is a function of the CIPHER-
+CHOICE:
+
+SSL_CK_RC4_128_WITH_MD5
+SSL_CK_RC4_128_EXPORT40_WITH_MD5
+SSL_CK_RC2_128_CBC_WITH_MD5
+SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
+SSL_CK_IDEA_128_CBC_WITH_MD5
+
+KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, 
+CONNECTION-ID ]
+KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, 
+CONNECTION-ID ]
+
+CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
+CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
+
+Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the KEY-
+MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the  most 
+significant byte of the CLIENT-READ-KEY.
+
+Data is fed to the MD5 hash function in the order shown, from left to 
+right: first the MASTER-KEY, then the "0" or "1", then the 
+CHALLENGE and then finally the CONNECTION-ID.
+
+Note that the "0" means the ascii zero character (0x30), not a zero value. 
+"1" means the ascii 1 character (0x31). MD5 produces 128 bits of output 
+data which are used directly as the key to the cipher algorithm (The most 
+significant byte of the MD5 output becomes the most significant byte of 
+the key material).
+
+SSL_CK_DES_64_CBC_WITH_MD5
+
+ KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, 
+CONNECTION-ID ]
+
+ CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
+ CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
+
+For DES-CBC, a single 16 bytes of key material are produced using MD5. 
+The first 8 bytes of the MD5 digest are used as the CLIENT-READ-KEY 
+while the remaining 8 bytes are used as the CLIENT-WRITE-KEY. The 
+initialization vector is provided in the KEY-ARG-DATA. Note that the 
+raw key data is not parity adjusted and that this step must be performed 
+before the keys are legitimate DES keys.
+
+SSL_CK_DES_192_EDE3_CBC_WITH_MD5
+
+
+Hickman							[page  10]
+
+ KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, 
+CONNECTION-ID ]
+ KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, 
+CONNECTION-ID ]
+ KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, 
+CONNECTION-ID ]
+
+ CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
+ CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
+ CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
+ CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
+ CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
+ CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
+
+Data is fed to the MD5 hash function in the order shown, from left to 
+right: first the MASTER-KEY, then the "0", "1" or "2", then the 
+CHALLENGE and then finally the CONNECTION-ID. Note that the 
+"0" means the ascii zero character (0x30), not a zero value. "1" means the 
+ascii 1 character (0x31). "2" means the ascii 2 character (0x32).
+
+A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher and 3 
+for the write side DES-EDE3 function. The initialization vector is 
+provided in the KEY-ARG-DATA. The keys that are produced are not 
+parity adjusted. This step must be performed before proper DES keys are 
+usable.
+
+Recall that the MASTER-KEY is given to the server in the CLIENT-
+MASTER-KEY message. The CHALLENGE is given to the server by 
+the client in the CLIENT-HELLO message. The CONNECTION-ID is 
+given to the client by the server in the SERVER-HELLO message. This 
+makes the resulting cipher keys a function of the original session and the 
+current session. Note that the master key is never directly used to encrypt 
+data, and therefore cannot be easily discovered.
+
+The CLIENT-MASTER-KEY message must be sent after the CLIENT-
+HELLO message and before the CLIENT-FINISHED message. The 
+CLIENT-MASTER-KEY message must be sent if the SERVER-
+HELLO message contains a SESSION-ID-HIT value of 0.
+
+5.5.3 CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
+
+char MSG-CLIENT-CERTIFICATE
+char CERTIFICATE-TYPE
+char CERTIFICATE-LENGTH-MSB
+char CERTIFICATE-LENGTH-LSB
+char RESPONSE-LENGTH-MSB
+char RESPONSE-LENGTH-LSB
+char CERTIFICATE-DATA[MSB<<8|LSB]
+char RESPONSE-DATA[MSB<<8|LSB]
+
+This message is sent by one an SSL client in response to a server 
+REQUEST-CERTIFICATE message. The CERTIFICATE-DATA 
+contains data defined by the CERTIFICATE-TYPE value. An ERROR 
+message is sent with error code NO-CERTIFICATE-ERROR when this 
+request cannot be answered properly (e.g. the receiver of the message has 
+
+Hickman							[page 11]
+
+no registered certificate).
+
+CERTIFICATE-TYPE is one of:
+
+SSL_X509_CERTIFICATE
+The CERTIFICATE-DATA contains an X.509 (1988) [3] signed 
+certificate.
+
+The RESPONSE-DATA contains the authentication response data. This 
+data is a function of the AUTHENTICATION-TYPE value sent by the 
+server.
+
+When AUTHENTICATION-TYPE is 
+SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-
+DATA contains a digital signature of the following components (in the 
+order shown):
+
+  the KEY-MATERIAL-0
+  the KEY-MATERIAL-1 (only if defined by the cipher kind)
+  the KEY-MATERIAL-2 (only if defined by the cipher kind)
+  the CERTIFICATE-CHALLENGE-DATA (from the 
+REQUEST-CERTIFICATE message)
+  the server's signed certificate (from the SERVER-HELLO 
+message)
+
+The digital signature is constructed using MD5 and then encrypted using 
+the clients private key, formatted according to PKCS#1's digital signature 
+standard [5]. The server authenticates the client by verifying the digital 
+signature using standard techniques. Note that other digest functions are 
+supported. Either a new AUTHENTICATION-TYPE can be added, or 
+the algorithm-id in the digital signature can be changed.
+
+This message must be sent by the client only in response to a REQUEST-
+CERTIFICATE message.
+
+5.5.4 CLIENT-FINISHED (Phase 2; Sent encrypted)
+
+char MSG-CLIENT-FINISHED
+char CONNECTION-ID[N-1]
+
+The client sends this message when it is satisfied with the server. Note that 
+the client must continue to listen for server messages until it receives a 
+SERVER-FINISHED message. The CONNECTION-ID data is the 
+original connection-identifier the server sent with its SERVER-HELLO 
+message, encrypted using the agreed upon session key.
+
+"N" is the number of bytes in the message that was sent, so "N-1" is the 
+number of bytes in the message without the message header byte.
+
+For version 2 of the protocol, the client must send this message after it has 
+received the SERVER-HELLO message. If the SERVER-HELLO 
+message SESSION-ID-HIT flag is non-zero then the CLIENT-
+FINISHED message is sent immediately, otherwise the CLIENT-
+FINISHED message is sent after the CLIENT-MASTER-KEY message.
+
+
+Hickman							[page 12]
+
+
+
+
+
+
+5.6 Server Only Protocol Messages
+
+There are several messages that are only generated by servers. The 
+messages are never generated by correctly functioning clients.
+
+5.6.1 SERVER-HELLO (Phase 1; Sent in the clear)
+
+char MSG-SERVER-HELLO
+char SESSION-ID-HIT
+char CERTIFICATE-TYPE
+char SERVER-VERSION-MSB
+char SERVER-VERSION-LSB
+char CERTIFICATE-LENGTH-MSB
+char CERTIFICATE-LENGTH-LSB
+char CIPHER-SPECS-LENGTH-MSB
+char CIPHER-SPECS-LENGTH-LSB
+char CONNECTION-ID-LENGTH-MSB
+char CONNECTION-ID-LENGTH-LSB
+char CERTIFICATE-DATA[MSB<<8|LSB]
+char CIPHER-SPECS-DATA[MSB<<8|LSB]
+char CONNECTION-ID-DATA[MSB<<8|LSB]
+
+The server sends this message after receiving the clients CLIENT-
+HELLO message. The server returns the SESSION-ID-HIT flag 
+indicating whether or not the received session-identifier is known by the 
+server (i.e. in the server's session-identifier cache). The SESSION-ID-
+HIT flag will be non-zero if the client sent the server a session-identifier 
+(in the CLIENT-HELLO message with SESSION-ID-LENGTH != 0) 
+and the server found the client's session-identifier in its cache. If the 
+SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, 
+CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will 
+be zero.
+
+The CERTIFICATE-TYPE value, when non-zero, has one of the values 
+described above (see the information on the CLIENT-CERTIFICATE 
+message).
+
+When the SESSION-ID-HIT flag is zero, the server packages up its 
+certificate, its cipher specs and a connection-id to send to the client. Using 
+this information the client can generate a session key and return it to the 
+server with the CLIENT-MASTER-KEY message.
+
+When the SESSION-ID-HIT flag is non-zero, both the server and the 
+client compute a new pair of session keys for the current session derived 
+from the MASTER-KEY that was exchanged when the SESSION-ID 
+was created. The SERVER-READ-KEY and SERVER-WRITE-KEY 
+are derived from the original MASTER-KEY keys in the same manner as 
+the CLIENT-READ-KEY and CLIENT-WRITE-KEY:
+
+SERVER-READ-KEY = CLIENT-WRITE-KEY
+SERVER-WRITE-KEY = CLIENT-READ-KEY
+
+Note that when keys are being derived and the SESSION-ID-HIT flag is 
+set and the server discovers the client's session-identifier in the servers 
+cache, then the KEY-ARG-DATA is used from the time when the 
+
+Hickman							[page 13]
+
+SESSION-ID was established. This is because the client does not send 
+new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in 
+the CLIENT-MASTER-KEY message).
+
+The CONNECTION-ID-DATA is a string of randomly generated bytes 
+used by the server and client at various points in the protocol. The 
+CLIENT-FINISHED message contains an encrypted version of the 
+CONNECTION-ID-DATA. The length of the CONNECTION-ID must 
+be between 16 and than 32 bytes, inclusive.
+
+The CIPHER-SPECS-DATA define a cipher type and key length (in bits) 
+that the receiving end supports. Each SESSION-CIPHER-SPEC is 3 
+bytes long and looks like this:
+
+char CIPHER-KIND-0
+char CIPHER-KIND-1
+char CIPHER-KIND-2
+
+Where CIPHER-KIND is one of:
+
+SSL_CK_RC4_128_WITH_MD5
+SSL_CK_RC4_128_EXPORT40_WITH_MD5
+SSL_CK_RC2_128_CBC_WITH_MD5
+SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
+SSL_CK_IDEA_128_CBC_WITH_MD5
+SSL_CK_DES_64_CBC_WITH_MD5
+SSL_CK_DES_192_EDE3_CBC_WITH_MD5
+
+This list is not exhaustive and may be changed in the future.
+
+The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4 
+cipher where some of the session key is sent in the clear and the rest is sent 
+encrypted (exactly 40 bits of it). MD5 is used as the hash function for 
+production of MAC's and session key's. This cipher type is provided to 
+support "export" versions (i.e. versions of the protocol that can be 
+distributed outside of the United States) of the client or server.
+
+An exportable implementation of the SSL Handshake Protocol will have 
+secret key lengths restricted to 40 bits. For non-export implementations 
+key lengths can be more generous (we recommend at least 128 bits). It is 
+permissible for the client and server to have a non-intersecting set of 
+stream ciphers. This, simply put, means they cannot communicate.
+
+Version 2 of the SSL Handshake Protocol defines the 
+SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The 
+SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of 
+128 bits. However, only 40 of the bits are secret (the other 88 bits are sent 
+in the clear by the client to the server).
+
+The SERVER-HELLO message is sent after the server receives the 
+CLIENT-HELLO message, and before the server sends the SERVER-
+VERIFY message.
+5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted)
+
+char MSG-SERVER-VERIFY
+
+Hickman							[page 14]
+
+char CHALLENGE-DATA[N-1]
+
+The server sends this message after a pair of session keys (SERVER-
+READ-KEY and SERVER-WRITE-KEY) have been agreed upon either 
+by a session-identifier or by explicit specification with the CLIENT-
+MASTER-KEY message. The message contains an encrypted copy of the 
+CHALLENGE-DATA sent by the client in the CLIENT-HELLO 
+message.
+
+"N" is the number of bytes in the message that was sent, so "N-1" is the 
+number of bytes in the CHALLENGE-DATA without the message 
+header byte.
+
+This message is used to verify the server as follows. A legitimate server 
+will have the private key that corresponds to the public key contained in 
+the server certificate that was transmitted in the SERVER-HELLO 
+message. Accordingly, the legitimate server will be able to extract and 
+reconstruct the pair of session keys (SERVER-READ-KEY and 
+SERVER-WRITE-KEY). Finally, only a server that has done the 
+extraction and decryption properly can correctly encrypt the 
+CHALLENGE-DATA. This, in essence, "proves" that the server has the 
+private key that goes with the public key in the server's certificate.
+
+The CHALLENGE-DATA must be the exact same length as originally 
+sent by the client in the CLIENT-HELLO message. Its value must match 
+exactly the value sent in the clear by the client in the CLIENT-HELLO 
+message. The client must decrypt this message and compare the value 
+received with the value sent, and only if the values are identical is the 
+server to be "trusted". If the lengths do not match or the value doesn't 
+match then the connection is to be closed by the client.
+
+This message must be sent by the server to the client after either detecting 
+a session-identifier hit (and replying with a SERVER-HELLO message 
+with SESSION-ID-HIT not equal to zero) or when the server receives the 
+CLIENT-MASTER-KEY message. This message must be sent before 
+any Phase 2 messages or a SERVER-FINISHED message.
+
+5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted)
+
+char MSG-SERVER-FINISHED
+char SESSION-ID-DATA[N-1]
+
+The server sends this message when it is satisfied with the clients security 
+handshake and is ready to proceed with transmission/reception of the 
+higher level protocols data. The SESSION-ID-DATA is used by the client 
+and the server at this time to add entries to their respective session-
+identifier caches. The session-identifier caches must contain a copy of the 
+MASTER-KEY sent in the CLIENT-MASTER-KEY message as the 
+master key is used for all subsequent session key generation.
+
+"N" is the number of bytes in the message that was sent, so "N-1" is the 
+number of bytes in the SESSION-ID-DATA without the message header 
+byte.
+
+This message must be sent after the SERVER-VERIFY message.
+
+Hickman							[page 15]
+
+5.6.4 REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
+
+char MSG-REQUEST-CERTIFICATE
+char AUTHENTICATION-TYPE
+char CERTIFICATE-CHALLENGE-DATA[N-2]
+
+A server may issue this request at any time during the second phase of the 
+connection handshake, asking for the client's certificate. The client 
+responds with a CLIENT-CERTIFICATE message immediately if it has 
+one, or an ERROR message (with error code NO-CERTIFICATE-
+ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is a 
+short byte string (whose length is greater than or equal to 16 bytes and less 
+than or equal to 32 bytes) that the client will use to respond to this 
+message.
+
+The AUTHENTICATION-TYPE value is used to choose a particular 
+means of authenticating the client. The following types are defined:
+
+SSL_AT_MD5_WITH_RSA_ENCRYPTION
+
+The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the 
+client construct an MD5 message digest using information as described 
+above in the section on the CLIENT-CERTIFICATE message. Once the 
+digest is created, the client encrypts it using its private key (formatted 
+according to the digital signature standard defined in PKCS#1). The server 
+authenticates the client when it receives the CLIENT-CERTIFICATE 
+message.
+
+This message may be sent after a SERVER-VERIFY message and before 
+a SERVER-FINISHED message.
+
+5.7 Client/Server Protocol Messages
+
+These messages are generated by both the client and the server.
+
+5.7.1 ERROR (Sent clear or encrypted)
+
+char MSG-ERROR
+char ERROR-CODE-MSB
+char ERROR-CODE-LSB
+
+This message is sent when an error is detected. After the message is sent, 
+the sending party shuts the connection down. The receiving party records 
+the error and then shuts its connection down.
+
+This message is sent in the clear if an error occurs during session key 
+negotiation. After a session key has been agreed upon, errors are sent 
+encrypted like all other messages.
+
+Appendix A: ASN.1 Syntax For Certificates
+
+Certificates are used by SSL to authenticate servers and clients. SSL 
+Certificates are based largely on the X.509 [3] certificates. An X.509 
+certificate contains the following information (in ASN.1 [1] notation):
+
+Hickman							[page 16]
+
+X.509-Certificate ::= SEQUENCE {
+  certificateInfo CertificateInfo,
+  signatureAlgorithm AlgorithmIdentifier,
+  signature BIT STRING
+}
+
+CertificateInfo ::= SEQUENCE {
+  version [0] Version DEFAULT v1988,
+  serialNumber CertificateSerialNumber,
+  signature AlgorithmIdentifier,
+  issuer Name,
+  validity Validity,
+  subject Name,
+  subjectPublicKeyInfo SubjectPublicKeyInfo
+}
+
+Version ::= INTEGER { v1988(0) }
+
+CertificateSerialNumber ::= INTEGER
+
+Validity ::= SEQUENCE {
+  notBefore UTCTime,
+  notAfter UTCTime
+}
+
+SubjectPublicKeyInfo ::= SEQUENCE {
+  algorithm AlgorithmIdentifier,
+  subjectPublicKey BIT STRING
+}
+
+AlgorithmIdentifier ::= SEQUENCE {
+  algorithm OBJECT IDENTIFIER,
+  parameters ANY DEFINED BY ALGORITHM OPTIONAL
+}
+
+For SSL's purposes we restrict the values of some of the X.509 fields:
+
+  The X.509-Certificate::signatureAlgorithm and 
+CertificateInfo::signature fields must be identical in value.
+
+  The issuer name must resolve to a name that is deemed acceptable by 
+the application using SSL. How the application using SSL does this is 
+outside the scope of this memo.
+
+Certificates are validated using a few straightforward steps. First, the 
+signature on the certificate is checked and if invalid, the certificate is 
+invalid (either a transmission error or an attempted forgery occurred). 
+Next, the CertificateInfo::issuer field is verified to be an issuer that the 
+application trusts (using an unspecified mechanism). The 
+CertificateInfo::validity field is checked against the current date and 
+verified.
+
+Finally, the CertificateInfo::subject field is checked. This check is 
+optional and depends on the level of trust required by the application using 
+SSL.
+
+Hickman							[page 17]
+
+Appendix B: Attribute Types and Object Identifiers
+
+SSL uses a subset of the X.520 selected attribute types as well as a
+few specific object identifiers. Future revisions of the SSL protocol
+may include support for more attribute types and more object
+identifiers.
+
+B.1 Selected attribute types
+
+commonName { attributeType 3 }
+The common name contained in the distinguished name contained 
+within a certificate issuer or certificate subject.
+
+countryName { attributeType 6 }
+The country name contained in the distinguished name contained 
+within a certificate issuer or certificate subject.
+
+localityName { attributeType 7 }
+The locality name contained in the distinguished name contained 
+within a certificate issuer or certificate subject.
+
+stateOrProvinceName { attributeType 8 }
+The state or province name contained in the distinguished name 
+contained within a certificate issuer or certificate subject.
+
+organizationName { attributeType 10 }
+The organization name contained in the distinguished name contained 
+within a certificate issuer or certificate subject.
+
+organizationalUnitName { attributeType 11 }
+The organizational unit name contained in the distinguished name 
+contained within a certificate issuer or certificate subject.
+
+B.2 Object identifiers
+
+md2withRSAEncryption { ... pkcs(1) 1 2 }
+The object identifier for digital signatures that use both MD2 and RSA 
+encryption. Used by SSL for certificate signature verification.
+
+md5withRSAEncryption { ... pkcs(1) 1 4 }
+The object identifier for digital signatures that use both MD5 and RSA 
+encryption. Used by SSL for certificate signature verification.
+
+rc4 { ... rsadsi(113549) 3 4 }
+The RC4 symmetric stream cipher algorithm used by SSL for bulk 
+encryption.
+
+Appendix C: Protocol Constant Values
+
+This section describes various protocol constants. A special value needs 
+mentioning - the IANA reserved port number for "https" (HTTP using 
+SSL). IANA has reserved port number 443 (decimal) for "https". IANA 
+has also reserved port number 465 for "ssmtp" and port number 563 for 
+"snntp".
+
+Hickman							[page 18]
+
+C.1 Protocol Version Codes
+
+#define SSL_CLIENT_VERSION 0x0002
+#define SSL_SERVER_VERSION 0x0002
+
+C.2 Protocol Message Codes
+
+The following values define the message codes that are used by version
+2 of the SSL Handshake Protocol.
+
+#define SSL_MT_ERROR			0
+#define SSL_MT_CLIENT_HELLO		1
+#define SSL_MT_CLIENT_MASTER_KEY	2
+#define SSL_MT_CLIENT_FINISHED		3
+#define SSL_MT_SERVER_HELLO		4
+#define SSL_MT_SERVER_VERIFY		5
+#define SSL_MT_SERVER_FINISHED		6
+#define SSL_MT_REQUEST_CERTIFICATE	7
+#define SSL_MT_CLIENT_CERTIFICATE	8
+
+C.3 Error Message Codes
+
+The following values define the error codes used by the ERROR message.
+
+#define SSL_PE_NO_CIPHER			0x0001
+#define SSL_PE_NO_CERTIFICATE 			0x0002
+#define SSL_PE_BAD_CERTIFICATE			0x0004
+#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE	0x0006
+
+C.4 Cipher Kind Values
+
+The following values define the CIPHER-KIND codes used in the 
+CLIENT-HELLO and SERVER-HELLO messages.
+
+#define SSL_CK_RC4_128_WITH_MD5		
+	0x01,0x00,0x80
+#define SSL_CK_RC4_128_EXPORT40_WITH_MD5	
+	0x02,0x00,0x80
+#define SSL_CK_RC2_128_CBC_WITH_MD5		
+	0x03,0x00,0x80
+#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
+	0x04,0x00,0x80
+#define SSL_CK_IDEA_128_CBC_WITH_MD5	
+	0x05,0x00,0x80
+#define SSL_CK_DES_64_CBC_WITH_MD5		
+	0x06,0x00,0x40
+#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5	
+	0x07,0x00,0xC0
+
+C.5 Certificate Type Codes
+
+The following values define the certificate type codes used in the 
+SERVER-HELLO and CLIENT-CERTIFICATE messages.
+
+#define SSL_CT_X509_CERTIFICATE		0x01
+
+Hickman							[page 19]
+
+C.6 Authentication Type Codes
+
+The following values define the authentication type codes used in the 
+REQUEST-CERTIFICATE message.
+
+#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
+
+C.7 Upper/Lower Bounds
+
+The following values define upper/lower bounds for various protocol 
+parameters.
+
+#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS	256
+#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES	16
+#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES	64
+#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER	32767
+#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER	16383
+
+C.8 Recommendations
+
+Because protocols have to be implemented to be of value, we recommend 
+the following values for various operational parameters. This is only a 
+recommendation, and not a strict requirement for conformance to the 
+protocol.
+
+Session-identifier Cache Timeout
+
+Session-identifiers are kept in SSL clients and SSL servers. Session-
+identifiers should have a lifetime that serves their purpose (namely, 
+reducing the number of expensive public key operations for a single 
+client/server pairing). Consequently, we recommend a maximum session-
+identifier cache timeout value of 100 seconds. Given a server that can 
+perform N private key operations per second, this reduces the server load 
+for a particular client by a factor of 100.
+
+Appendix D: Attacks
+
+In this section we attempt to describe various attacks that might be used 
+against the SSL protocol. This list is not guaranteed to be exhaustive. SSL 
+was defined to thwart these attacks.
+
+D.1 Cracking Ciphers
+
+SSL depends on several cryptographic technologies. RSA Public Key 
+encryption [5] is used for the exchange of the session key and client/server 
+authentication. Various cryptographic algorithms are used for the session 
+cipher. If successful cryptographic attacks are made against these 
+technologies then SSL is no longer secure.
+
+Attacks against a specific communications session can be made by 
+recording the session, and then spending some large number of compute 
+cycles to crack either the session key or the RSA public key until the 
+communication can be seen in the clear. This approach is easier than 
+cracking the cryptographic technologies for all possible messages. Note 
+that SSL tries to make the cost of such of an attack greater than the 
+
+Hickman							[page 20]
+
+benefits gained from a successful attack, thus making it a waste of 
+money/time to perform such an attack.
+
+There have been many books [9] and papers [10] written on cryptography. 
+This document does not attempt to reference them all.
+
+D.2 Clear Text Attack
+
+A clear text attack is done when the attacker has an idea of what kind of 
+message is being sent using encryption. The attacker can generate a data 
+base whose keys are the encrypted value of the known text (or clear text), 
+and whose values are the session cipher key (we call this a "dictionary"). 
+Once this data base is constructed, a simple lookup function identifies the 
+session key that goes with a particular encrypted value. Once the session 
+key is known, the entire message stream can be decrypted. Custom 
+hardware can be used to make this cost effective and very fast.
+
+Because of the very nature of SSL clear text attacks are possible. For 
+example, the most common byte string sent by an HTTP client application 
+to an HTTP server is "GET". SSL attempts to address this attack by using 
+large session cipher keys. First, the client generates a key which is larger 
+than allowed by export, and sends some of it in the clear to the server (this 
+is allowed by United States government export rules). The clear portion of 
+the key concatenated with the secret portion make a key which is very 
+large (for RC4, exactly 128 bits).
+
+The way that this "defeats" a clear text attack is by making the amount of 
+custom hardware needed prohibitively large. Every bit added to the length 
+of the session cipher key increases the dictionary size by a factor of 2. By 
+using a 128 bit session cipher key length the size of the dictionary required 
+is beyond the ability of anyone to fabricate (it would require more atoms to 
+construct than exist in the entire universe). Even if a smaller dictionary is 
+to be used, it must first be generated using the clear key bits. This is a time 
+consumptive process and also eliminates many possible custom hardware 
+architectures (e.g. static prom arrays).
+
+The second way that SSL attacks this problem is by using large key 
+lengths when permissible (e.g. in the non-export version). Large key sizes 
+require larger dictionaries (just one more bit of key size doubles the size of 
+the dictionary). SSL attempts to use keys that are 128 bits in length.
+
+Note that the consequence of the SSL defense is that a brute force attack 
+becomes the cheapest way to attack the key. Brute force attacks have well 
+known space/time tradeoffs and so it becomes possible to define a cost of 
+the attack. For the 128 bit secret key, the known cost is essentially infinite. 
+For the 40 bit secret key, the cost is much smaller, but still outside the 
+range of the "random hacker".
+
+D.3 Replay
+
+The replay attack is simple. A bad-guy records a communication session 
+between a client and server. Later, it reconnects to the server, and plays 
+back the previously recorded client messages.  SSL defeats this attack 
+using a "nonce" (the connection-id) which is "unique" to the connection. In 
+theory the bad-guy cannot predict the nonce in advance as it is based on a 
+
+Hickman							[page 21]
+
+set of random events outside the bad-guys control, and therefore the bad-
+guy cannot respond properly to server requests.
+
+A bad-guy with large resources can record many sessions between a client 
+and a server, and attempt to choose the right session based on the nonce 
+the server sends initially in its SERVER-HELLO message. However, SSL 
+nonces are at least 128 bits long, so a bad-guy would need to record 
+approximately 2^64 nonces to even have a 50% chance of choosing the 
+right session. This number is sufficiently large that one cannot 
+economically construct a device to record 2^64 messages, and therefore 
+the odds are overwhelmingly against the replay attack ever being 
+successful.
+
+D.4 The Man In The Middle
+
+The man in the middle attack works by having three people in a 
+communications session: the client, the server, and the bad guy. The bad 
+guy sits between the client and the server on the network and intercepts 
+traffic that the client sends to the server, and traffic that the server
+sends to 
+the client.
+
+The man in the middle operates by pretending to be the real server to the 
+client. With SSL this attack is impossible because of the usage of server 
+certificates. During the security connection handshake the server is 
+required to provide a certificate that is signed by a certificate authority. 
+Contained in the certificate is the server's public key as well as its name 
+and the name of the certificate issuer. The client verifies the certificate by 
+first checking the signature and then verifying that the name of the issuer 
+is somebody that the client trusts.
+
+In addition, the server must encrypt something with the private key that 
+goes with the public key mentioned in the certificate. This in essence is a 
+single pass "challenge response" mechanism. Only a server that has both 
+the certificate and the private key can respond properly to the challenge.
+
+If the man in the middle provides a phony certificate, then the signature 
+check will fail. If the certificate provided by the bad guy is legitimate, but 
+for the bad guy instead of for the real server, then the signature will pass 
+but the name check will fail (note that the man in the middle cannot forge 
+certificates without discovering a certificate authority's private key).
+
+Finally, if the bad guy provides the real server's certificate then the 
+signature check will pass and the name check will pass. However, because 
+the bad guy does not have the real server's private key, the bad guy cannot 
+properly encode the response to the challenge code, and this check will 
+fail.
+
+In the unlikely case that a bad guy happens to guess the response code to 
+the challenge, the bad guy still cannot decrypt the session key and 
+therefore cannot examine the encrypted data.
+
+
+Hickman							[page 22]
+
+Appendix E: Terms
+
+Application Protocol
+An application protocol is a protocol that normally layers directly on 
+top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP.
+
+Authentication
+Authentication is the ability of one entity to determine the identity of 
+another entity. Identity is defined by this document to mean the 
+binding between a public key and a name and the implicit ownership 
+of the corresponding private key.
+
+Bulk Cipher
+This term is used to describe a cryptographic technique with certain 
+performance properties. Bulk ciphers are used when large quantities of 
+data are to be encrypted/decrypted in a timely manner. Examples 
+include RC2, RC4, and IDEA.
+
+Client
+In this document client refers to the application entity that is initiates a 
+connection to a server.
+
+CLIENT-READ-KEY
+The session key that the client uses to initialize the client read cipher. 
+This key has the same value as the SERVER-WRITE-KEY.
+
+CLIENT-WRITE-KEY
+The session key that the client uses to initialize the client write cipher. 
+This key has the same value as the SERVER-READ-KEY.
+
+MASTER-KEY
+The master key that the client and server use for all session key 
+generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, 
+SERVER-READ-KEY and SERVER-WRITE-KEY are generated 
+from the MASTER-KEY.
+
+MD2
+MD2 [8] is a hashing function that converts an arbitrarily long data 
+stream into a digest of fixed size. This function predates MD5 [7] 
+which is viewed as a more robust hash function [9].
+
+MD5
+MD5 [7] is a hashing function that converts an arbitrarily long data 
+stream into a digest of fixed size. The function has certain properties 
+that make it useful for security, the most important of which is it's 
+inability to be reversed.
+
+Nonce
+A randomly generated value used to defeat "playback" attacks. One 
+party randomly generates a nonce and sends it to the other party. The 
+receiver encrypts it using the agreed upon secret key and returns it to 
+the sender. Because the nonce was randomly generated by the sender 
+this defeats playback attacks because the replayer can't know in 
+advance the nonce the sender will generate. The receiver denies 
+connections that do not have the correctly encrypted nonce.
+
+Hickman							[page 23]
+
+Non-repudiable Information Exchange
+When two entities exchange information it is sometimes valuable to 
+have a record of the communication that is non-repudiable. Neither 
+party can then deny that the information exchange occurred. Version 2 
+of the SSL protocol does not support Non-repudiable information 
+exchange.
+
+Public Key Encryption
+Public key encryption is a technique that leverages asymmetric ciphers. 
+A public key system consists of two keys: a public key and a private 
+key. Messages encrypted with the public key can only be decrypted 
+with the associated private key. Conversely, messages encrypted with 
+the private key can only be decrypted with the public key. Public key 
+encryption tends to be extremely compute intensive and so is not 
+suitable as a bulk cipher.
+
+Privacy
+Privacy is the ability of two entities to communicate without fear of 
+eavesdropping. Privacy is often implemented by encrypting the 
+communications stream between the two entities.
+
+RC2, RC4
+Proprietary bulk ciphers invented by RSA (There is no good reference 
+to these as they are unpublished works; however, see [9]). RC2 is 
+block cipher and RC4 is a stream cipher.
+
+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 cipher
+A session cipher is a "bulk" cipher that is capable of encrypting or 
+decrypting arbitrarily large amounts of data. Session ciphers are used 
+primarily for performance reasons. The session ciphers used by this 
+protocol are symmetric. Symmetric ciphers have the property of using 
+a single key for encryption and decryption.
+
+Session identifier
+A session identifier is a random value generated by a client that 
+identifies itself to a particular server. The session identifier can be 
+thought of as a handle that both parties use to access a recorded secret 
+key (in our case a session key). If both parties remember the session 
+identifier then the implication is that the secret key is already known 
+and need not be negotiated.
+
+Session key
+The key to the session cipher. In SSL there are four keys that are called 
+session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, 
+SERVER-READ-KEY, and SERVER-WRITE-KEY.
+
+SERVER-READ-KEY
+The session key that the server uses to initialize the server read cipher. 
+This key has the same value as the CLIENT-WRITE-KEY.
+
+
+Hickman							[page 24]
+
+SERVER-WRITE-KEY
+The session key that the server uses to initialize the server write cipher. 
+This key has the same value as the CLIENT-READ-KEY.
+
+Symmetric Cipher
+A symmetric cipher has the property that the same key can be used for 
+decryption and encryption. An asymmetric cipher does not have this 
+behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.
+
+
+
+References
+
+[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax 
+Notation One (ASN.1). 1988.
+
+[2] CCITT. Recommendation X.209: "Specification of Basic Encoding 
+Rules for Abstract Syntax Notation One (ASN.1). 1988.
+
+[3] CCITT. Recommendation X.509: "The Directory - Authentication 
+Framework". 1988.
+
+[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute 
+Types". 1988.
+
+[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, 
+November 1993.
+
+[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, 
+Version 1.5, November 1993.
+
+[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 
+1992.
+
+[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 
+1992.
+
+[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source 
+Code in C, Published by John Wiley & Sons, Inc. 1994.
+
+[10] M. Abadi and R. Needham. Prudent engineering practice for 
+cryptographic protocols. 1994.
+
+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 and the Board of Trustees of 
+the Leland Stanford Junior University have granted Public Key Partners 
+(PKP) exclusive sub-licensing rights to the following patents issued in the 
+
+Hickman							[page 25]
+
+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
+
+Cryptographic Communications System and Method ("RSA")		
+	No. 4,405,829
+
+Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig")	
+	No. 4,424,414
+
+These patents are stated by PKP to cover all known methods of practicing 
+the art of Public Key encryption, including the variations collectively 
+known as ElGamal.
+
+Public Key Partners has provided written assurance to the Internet Society 
+that parties will be able to obtain, under reasonable, nondiscriminatory 
+terms, the right to use the technology covered by these patents. This 
+assurance is documented in RFC 1170 titled "Public Key Standards and 
+Licenses". A copy of the written assurance dated April 20, 1990, may be 
+obtained from the Internet Assigned Number Authority (IANA).
+
+The Internet Society, Internet Architecture Board, Internet Engineering 
+Steering Group and the Corporation for National 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 user's own responsibility.
+
+Security Considerations
+
+This entire document is about security.
+
+Author's Address
+
+Kipp E.B. Hickman
+Netscape Communications Corp.
+501 East Middlefield Rd.
+Mountain View, CA 94043
+kipp@netscape.com
+
+
+Hickman							[page 26]
+
+
+
+
+
+
+