diff options
author | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2003-11-27 21:52:50 +0000 |
---|---|---|
committer | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2003-11-27 21:52:50 +0000 |
commit | 2c39ed5e0101593043a4656e22c95c219b29ca8c (patch) | |
tree | 1ebc322d732f378866b8c3cf57481458a1c6c3b3 | |
parent | 84d04f0b3dcc9905c9d8942b6c872a0c44850ade (diff) | |
download | gnutls-2c39ed5e0101593043a4656e22c95c219b29ca8c.tar.gz |
Added historical documents. Got from http://www21.ocn.ne.jp/~k-west/SSLandTLS/index-e.html
-rw-r--r-- | doc/protocol/draft-benaloh-pct-00.txt | 1684 | ||||
-rw-r--r-- | doc/protocol/draft-benaloh-pct-01.txt | 2649 | ||||
-rw-r--r-- | doc/protocol/draft-hickman-netscape-ssl-00.txt | 1510 |
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] + + + + + + + |