Microsoft Corporation's PCT Protocol

September 1995

First draft, PCT 1.0.

October 1995

Revised draft, PCT 1.0. Improved readability, several minor typos corrected (including one in SERVER_MAC_KEY derivation expression), block cipher IV use clarified, and a few constant values added.

April 1996

First draft, PCT 2.0. Adds features to and is fully backwards compatible with PCT 1.0.

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, sentrespectively 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 ield 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 he 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, nd 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 message, 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, thenthe 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 rror, 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

This Internet-Draft expires 10 October 1996.