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

1 files changed, 1684 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]
+
+