idnits 2.17.1 draft-benaloh-pct-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 82 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1995) is 10414 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 158, but not defined == Missing Reference: '32' is mentioned on line 913, but not defined == Unused Reference: '12' is defined on line 1457, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Josh Benaloh 2 Butler Lampson 3 Daniel Simon 4 Terence Spies 5 Bennet Yee 6 Microsoft Corp. 7 October 1995 9 The Private Communication Technology Protocol 10 12 1. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 This Internet-Draft expires 27 March 1996. 31 2. Abstract 33 This document specifies Version 1 of the Private Communication 34 Technology (PCT) protocol, a security protocol that provides privacy 35 over the Internet. Like SSL (see [1]), the protocol is intended to 36 prevent eavesdropping on communications in client/server applications, 37 with servers always being authenticated and clients being 38 authenticated at the server's option. However, this protocol corrects 39 or improves on several weaknesses of SSL. 41 3. Introduction 43 The Private Communication Technology (PCT) Protocol is designed to 44 provide privacy between two communicating applications (a client and a 45 server), and to authenticate the server and (optionally) the client. 46 PCT assumes a reliable transport protocol (e.g. TCP) for data 47 transmission and reception. 49 The PCT Protocol is application protocol-independent. A "higher 50 level" application protocol (e.g. HTTP, FTP, TELNET, etc.) can layer 51 on top of the PCT Protocol transparently. The PCT Protocol begins 52 with a handshake phase that negotiates an encryption algorithm and 53 (symmetric) session key as well as authenticating a server to the 54 client (and, optionally, vice versa), based on certified asymmetric 55 public keys. Once transmission of application protocol data begins, 56 all data is encrypted using the session key negotiated during the 57 handshake. 59 It should be noted that the PCT protocol does not specify any details 60 about verification of certificates with respect to certification 61 authorities, revocation lists, and so on. Rather, it is assumed that 62 protocol implementations have access to a "black box" which is capable 63 of ruling on the validity of received certificates in a manner 64 satisfactory to the implementation's user. Such a ruling may, for 65 instance, involve remote consultation with a trusted service, or even 66 with the actual user through a text or graphic interface. 68 In addition to encryption and authentication, the PCT protocol 69 verifies the integrity of messages using a hash function-based message 70 authentication code (MAC). 72 The PCT protocol's record format is compatible with that of SSL (see 73 [1]). Servers implementing both protocols can distinguish between PCT 74 and SSL clients because the version number field occurs in the same 75 position in the first handshake message in both protocols. In PCT, 76 the most significant bit of the protocol version number is set to one. 78 The PCT protocol differs from SSL chiefly in the design of its 79 handshake phase, which differs from SSL's in a number of respects: 81 - The round and message structures are considerably shorter and 82 simpler: a reconnected session without client authentication 83 requires only one message in each direction, and no other type of 84 connection requires more than two messages in each direction. 86 - Negotiation for the choice of cryptographic algorithms and formats 87 to use in a session has been extended to cover more protocol 88 characteristics and to allow different characteristics to be 89 negotiated independently. The PCT client and server negotiate, in 90 addition to a cipher type and server certificate type, a hash 91 function type and a key exchange type. If client authentication is 92 requested, a client certificate type and signature type are also 93 negotiated. 95 - Message authentication has been revamped so that it now uses 96 different keys from the encryption keys. Thus, message 97 authentication keys may be much longer (and message authentication 98 therefore much more secure) than the encryption keys, which may be 99 weak or even non-existent. 101 - A security hole in SSL's client authentication has been repaired; 102 the PCT client's authentication challenge response now depends on 103 the type of cipher negotiated for the session. SSL's client 104 authentication is independent of the cipher strength used in the 105 session and also of whether the authentication is being performed 106 for a reconnection of an old session or for a new one. As a result, 107 a "man-in-the-middle" attacker who has obtained the session key for 108 a session using weak cryptography can use this broken session to 109 authenticate as the client in a session using strong cryptography. 110 If, for example, the server normally restricts certain sensitive 111 functions to high-security sessions, then this security hole allows 112 intruders to circumvent the restriction. 114 - A "verify-prelude" field has been added to the handshake phase, 115 with which the client and server can check that the cipher type 116 (and other) negotiations carried out in the clear have not been 117 tampered with. (SSL version 3 uses a similar mechanism, but its 118 complete version 2 compatibility negates its security function, 119 by allowing adversaries simply to alter version numbers as well 120 as cipher types.) 122 4. PCT Record Protocol Specification 124 4.1 PCT Record Header Format 126 For compatibility with SSL, the PCT protocol uses the same basic 127 record format as SSL. In PCT, all data sent is encapsulated in a 128 record, an object which is composed of a header and some non-zero 129 amount of data. Each record header contains a two- or three-byte 130 length code. If the most significant bit is set in the first byte of 131 the record length code then the record has no padding and the total 132 header length is two bytes; otherwise the record has padding and the 133 total header length is three bytes. The record header is transmitted 134 before the data portion of the record. 136 Note that in the long header case (three bytes total), the second most 137 significant bit in the first byte has special meaning. When zero, the 138 record being sent is a data record. When one, the record being sent 139 is a security escape, and the first byte of the record is an 140 ESCAPE_TYPE_CODE that indicates the type of escape. (Currently, the 141 two examples of security escapes are the "out-of-band data" escape and 142 the "redo handshake" escape.) In either case, the length code 143 describes how much data is in the record as transmitted; this may be 144 greater than the amount of data after decryption, particularly if 145 padding was used. 147 The record length code does not include the number of bytes consumed 148 by the record header (two or three). For the two-byte header, the 149 record length is computed by (using a "C"-like notation): 151 RECORD_LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1], 153 where byte[0] represents the first byte received and byte[1] the 154 second byte received. When the three-byte header is used, the record 155 length is computed as follows (using a "C"-like notation): 157 RECORD_LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1]; 158 IS_ESCAPE = (byte[0] & 0x40) != 0; 159 PADDING_LENGTH = byte[2]; 161 The record header defines a value called PADDING_LENGTH. The 162 PADDING_LENGTH value specifies how many bytes of data were appended 163 to the original record by the sender. The padding data is used to 164 make the record length a multiple of the block cipher's block size 165 when a block cipher is used for encryption. 167 The sender of a "padded" record appends the padding data to the end of 168 its normal data and then encrypts the total amount (which is now a 169 multiple of the block cipher's block size). The actual value of the 170 padding data is unimportant, but the encrypted form of it must be 171 transmitted for the receiver to decrypt the record properly. Once the 172 total amount being transmitted is known the header can be properly 173 constructed with the PADDING value set appropriately. 175 The receiver of a padded record uses the PADDING_LENGTH value from the 176 header when determining the length of the ACTUAL_DATA in the data 177 record (see section 4.2). 179 4.2 PCT Record Data Format 181 The format of the data portion of an encrypted PCT record is slightly 182 different from that of SSL. However, not only is the record header 183 format identical in both protocols, but the first handshake message 184 sent in each direction is also sent in the clear, and contains a 185 version number field in the same location in both protocols. (In PCT 186 protocol handshake messages, the most significant bit of this field is 187 1.) Hence, PCT is still compatible with SSL, in the sense that PCT 188 handshake messages can be recognized and distinguished from SSL 189 handshake messages by examination of the version number. 191 The PCT record is composed of two fields (transmitted and received in 192 the order shown): 194 ENCRYPTED_DATA[N+PADDING_LENGTH] 195 MAC_DATA[MAC_LENGTH] 197 The ENCRYPTED_DATA field contains an encryption of the concatenation 198 of ACTUAL_DATA (the N bytes of actual data being transmitted) and 199 PADDING_DATA (the use of which is explained below). The MAC_DATA 200 field contains the "Message Authentication Code" (MAC). 202 PCT handshake records are sent in the clear, and no MAC is used. 203 Consequently PADDING_LENGTH will be zero and MAC_LENGTH will be zero. 204 For non-handshake data records, the sender appends a PADDING_DATA 205 field containing arbitrary data, so that N + PADDING_LENGTH is the 206 appropriate length for the cipher being used to encrypt the data. (In 207 the case where a block cipher is used, PADDING_LENGTH must be the 208 minimum value such that the length of the concatenation of ACTUAL_DATA 209 and PADDING_DATA is an exact multiple of the cipher's block size. 210 Otherwise, PADDING_LENGTH is zero.) 212 MAC_DATA is computed as follows: 214 MAC_DATA := Hash( MAC_KEY, Hash( ACTUAL_DATA, PADDING_DATA, 215 SEQUENCE_NUMBER ) ) 217 If the client is sending the record, then the MAC_KEY is the 218 CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY 219 is the SERVER_MAC_KEY. (The details of the derivation of these keys 220 are given in section 5.3.1.) The selection of the hash function used 221 to compute MAC_DATA is discussed in sections 5.2.1 and 5.2.2. The 222 parameters of the inner invocation of the hash function are input into 223 the hash function in the order shown above, with SEQUENCE_NUMBER 224 represented in network byte order or "big endian" order. If the 225 length of MAC_KEY is not an exact multiple of eight bits, then MAC_KEY 226 is considered, for the purposes of MAC computation, to have (fewer 227 than eight) zero bits appended to it, to create a string of an 228 integral number of bytes for input into the MAC hash function. 230 The SEQUENCE_NUMBER is a counter which is incremented by both the 231 sender and the receiver. For each transmission direction, a pair of 232 counters is kept (one by the sender, one by the receiver). Before the 233 first (handshake) record is sent or received in a PCT connection all 234 sequence numbers are initialized to zero (except in the case of a 235 restarting connection with a token-based exchange type, in which case 236 the entire cipher state is preserved; see section 5.2.2). The 237 sender's sender-to-receiver sequence number is incremented after every 238 record sent, and the receiver's sender-to-receiver sequence number is 239 incremented after every record received. Sequence numbers are 32-bit 240 unsigned quantities, and may not increment past 0xFFFFFFFF. (See 241 section 4.3.2.) 243 The receiver of a record (whether PCT client or server) first uses the 244 sender's WRITE_KEY to decrypt the concatenated ACTUAL_DATA and 245 PADDING_DATA fields, then uses the sender's MAC_KEY, the ACTUAL_DATA, 246 the PADDING_DATA, and the expected value of the sequence number as 247 input into the MAC_DATA function described above (the hash function 248 algorithm used is determined the same way for the receiver as for the 249 sender). The computed MAC_DATA must agree bit for bit with the 250 transmitted MAC_DATA. If the two are not identical, then an 251 INTEGRITY_CHECK_FAILED error occurs, and it is recommended that the 252 record be treated as though it contained no data. (See section 5.4.) 253 The same error occurs if N + PADDING_LENGTH is not correct for the 254 block cipher used. 256 The PCT Record Layer is used for all PCT communications, including 257 handshake messages, security escapes and application data transfers. 258 The PCT Record Layer is used by both the client and the server at all 259 times. 261 For a two-byte header, the maximum record length is 32767 bytes. For 262 a three-byte header, the maximum record length is 16383 bytes. The 263 PCT Handshake Protocol messages are constrained to fit in a single PCT 264 Record Protocol record. Application protocol messages are allowed to 265 consume multiple PCT Record Protocol records. 267 4.3 Security Escapes 269 4.3.1 Out-Of-Band Data 271 PCT, like SSL, supports the transmission and reception of "out-of-band 272 data". Out of band data is normally defined at the TCP/IP protocol 273 level, but because of PCT's privacy enhancements and support for block 274 ciphers, this becomes difficult to support. 276 To send out-of-band data, the sender sends an escape record whose body 277 contains a single byte of data which is the ESCAPE_TYPE_CODE value 278 PCT_ET_OOB_DATA. The record following the escape record will be 279 interpreted as "out-of-band" data and will only be made available to 280 the receiver through an unspecified mechanism that is different from 281 the receiver's normal data reception method. The escape record and 282 the transmitted data record are transmitted normally (i.e. encryption, 283 MAC computations, and block cipher padding remain in effect). 285 Note that the escape record and the associated data record are sent 286 using normal TCP sending mechanisms, not using the "out of band" 287 mechanisms. Note also that a "Redo Handshake" escape record (see 288 below) and its associated handshake messages may be interposed between 289 an "Out-of-Band Data" escape record and its associated data record. 290 In such a case, the first non-escape, non-handshake record following 291 the "Out-of-Band Data" escape record is treated as out-of-band data. 293 4.3.2 Redo Handshake 295 PCT allows either the client or the server to request, at any time 296 after the handshake phase has been completed for a connection, that 297 another handshake phase be performed for that connection. For 298 example, either party is required to request another handshake phase 299 rather than allow its sequence number to "wrap" beyond 0xFFFFFFFF. In 300 addition, it is recommended that implementations enforce limits on the 301 duration of both connections and sessions, with respect to the total 302 number of bytes sent, the number of records sent, the actual time 303 elapsed since the beginning of the connection or session, and, in the 304 case of sessions, the number of reconnections made. These limits 305 serve to ensure that keys are not used more or longer than it is safe 306 to do so; hence the limits may depend on the type and strength of 307 cipher, key exchange and authentication used, and may, at the 308 implementer's discretion, include indications from the application as 309 to the sensitivity of the data being transmitted or received. 311 To request a new handshake phase for this connection, the sender 312 (client or server) sends an escape record whose body contains a single 313 byte of data which is the ESCAPE_TYPE_CODE value PCT_ET_REDO_CONN. 314 The escape record is transmitted normally (i.e. encryption, MAC 315 computations, and block cipher padding remain in effect). 317 There are several cases to consider to ensure that the message 318 pipeline gets flushed and to enable handshake messages to be 319 distinguished from data records. The following rules ensure that the 320 first messages in the redone handshake are always immediately preceded 321 by a "Redo Handshake" escape message. 323 If the client initiates the "Redo Handshake", it sends the "Redo 324 Handshake" escape message immediately followed by a normal 325 CLIENT_HELLO message; the server, on receiving the "Redo Handshake" 326 escape message, may be in one of two states. If the last message it 327 sent was a "Redo Handshake" escape message, then it simply waits for 328 the CLIENT_HELLO message; otherwise, it sends a "Redo Handshake" 329 escape message in response, and then waits for the CLIENT_HELLO 330 message. 332 If the server initiates the "Redo Handshake", then the server sends 333 the "Redo Handshake" escape message and simply waits for a "Redo 334 Handshake" escape message in response; this "Redo Handshake" should be 335 immediately followed by a normal CLIENT_HELLO message. The client, on 336 receiving the server's "Redo Handshake" escape message, may be in one 337 of two states. If the last two messages it sent were a "Redo 338 Handshake" escape message followed by a CLIENT_HELLO message, then it 339 simply waits for a SERVER_HELLO message; otherwise, it sends a "Redo 340 Handshake" escape message in response, followed by a CLIENT_HELLO 341 message, and then waits for a SERVER_HELLO message. 343 In all cases, the sender of the "Redo Handshake" escape message 344 continues to process incoming messages, but may not send any 345 non-handshake messages until the new handshake completes. 347 The handshake phase that follows the "Redo Handshake" escape message 348 is a normal one in most respects; the client may request the 349 reconnection of an old session or request that a new session be 350 initiated, and the server, on receiving a reconnection request, can 351 accept the reconnection or demand that a new session be initiated 352 instead. If a new session is being established, then the server must 353 request client authentication if and only if client authentication 354 was requested during the previous session. Otherwise, client 355 authentication is optional. Both parties must verify that the 356 specifications negotiated previously in the session (cipher type, key 357 exchange type, certificate type, hash function type, client 358 certificate type, and signature type), as well as any certificates 359 exchanged, are identical to those found in the new handshake phase. 360 A mismatch results in a SPECS_MISMATCH or BAD_CERTIFICATE error (see 361 section 5.4.) This ensures that the security properties of the 362 communication channel do not change. 364 5. PCT Handshake Protocol Specification 366 5.1 PCT Handshake Protocol Flow 368 The PCT Handshake Protocol is used to negotiate security enhancements 369 to data sent using the PCT Record Protocol. The security enhancements 370 consist of authentication, symmetric encryption, and message 371 integrity. Symmetric encryption is facilitated using a "Key Exchange 372 Algorithm". PCT version 1 supports RSA {TM} -based key exchange (see 373 [13]), Diffie-Hellman key exchange, and FORTEZZA token key exchange. 375 The PCT Handshake Protocol consists of four messages, sent 376 respectively by the client, then server, then client, then server, in 377 that order. (Moreover, under certain circumstances, the last two 378 messages are omitted.) The messages are named, in order, 379 CLIENT_HELLO, SERVER_HELLO, CLIENT_MASTER_KEY, and SERVER_VERIFY. 381 The general contents of the messages depend upon two criteria: whether 382 the connection being made is a reconnection (a continuation of a 383 previous session) or a new session and whether the client is to be 384 authenticated. (The server is always authenticated.) The first 385 criterion is determined by the client and server together; the 386 CLIENT_HELLO will have different contents depending on whether a new 387 session is being initiated or an old one continued, and the 388 SERVER_HELLO message will either confirm a requested continuation of 389 an old session, or require that a new session be initiated. The 390 second criterion is determined by the server, whose SERVER_HELLO may 391 contain a demand for authentication of the client. If the server does 392 not require client authentication, and the reconnection of an old 393 session is requested by the client and accepted by the server, then 394 the CLIENT_MASTER_KEY and SERVER_VERIFY messages are unnecessary, and 395 are omitted. 397 The CLIENT_HELLO message contains a random authentication challenge 398 to the server and a request for the type and level of cryptography 399 and certification to be used for the session. If the client is 400 attempting to continue an old session, then it also supplies that 401 session's ID. 403 In the case of a new session, the SERVER_HELLO message contains a 404 certificate and a random connection identifier; this identifier 405 doubles as an authentication challenge to the client if the server 406 desires client authentication. The CLIENT_MASTER_KEY message sent by 407 the client in response includes the master key for the session (from 408 which session keys are derived), encrypted using the public key from 409 the server's certificate, as well as a certificate and response to the 410 server's authentication challenge, if requested. To ensure that 411 previous unencrypted handshake messages were not tampered with, their 412 keyed hash is included with the CLIENT_MASTER_KEY message. Finally, 413 the server sends a SERVER_VERIFY message which includes a response to 414 the client's challenge and a random session id for the session. 416 If the server accepts the old session id, then the SERVER_HELLO 417 message contains a response to the client's challenge, and a random 418 connection identifier which again doubles as a random challenge to the 419 client, if the server requires client authentication. If no client 420 authentication is requested, the handshake is finished (although an 421 authentication of the client is implicit in the MAC included with the 422 client's first data message). Otherwise, the subsequent 423 CLIENT_MASTER_KEY message contains the client's response, and the 424 SERVER_VERIFY message simply signals to the client to continue. 426 For a new session, the handshake phase has the following form (items 427 in square brackets are included only if client authentication is 428 required): 430 Client Server 431 ------ ------ 433 CLIENT_HELLO: 434 client challenge; 435 client's cipher, hash, 436 server-certificate, 437 and key-exchange 438 specification lists 440 SERVER_HELLO: 441 connection id/server challenge; 442 server's cipher, hash, 443 server-certificate, 444 and key-exchange 445 specification choices; 446 server certificate 447 [; server's signature-type 448 and client-certificate 449 specification lists] 451 CLIENT_MASTER_KEY: 452 master key, encrypted with 453 server's public key; 454 authentication of previous two 455 messages 456 [; client's signature-type and 457 client-certificate 458 specification choices; 459 client's certificate; 460 client's challenge response] 462 SERVER_VERIFY: 463 session id; 464 server's challenge response 466 For a reconnection of an old session, the handshake phase has the 467 following form (items in square brackets are included if client 468 authentication is required): 470 Client Server 471 ------ ------ 473 CLIENT_HELLO: 474 client challenge; 475 session id; 476 client's cipher, hash, 477 server-certificate, 478 and key-exchange 479 specification lists 481 SERVER_HELLO: 482 connection id/server challenge; 483 old session's cipher, hash, 484 server-certificate, 485 and key-exchange 486 specification choices; 487 server's challenge response 488 [; server's signature-type 489 and client-certificate 490 specification lists] 492 [CLIENT_MASTER_KEY: 493 client's certificate; 494 client's challenge response] 496 [SERVER_VERIFY] 498 Note that the protocol is asymmetric between client and server. The 499 client authenticates the server because only the server can decrypt 500 the master key which is encrypted with the server's public key, and 501 the server's challenge response depends on knowing that master key. 502 The server authenticates the client because the client signs its 503 challenge response with its public key. The reason for the asymmetry 504 is that when there is no client authentication there is no client 505 public key, so the client must choose the master key and encrypt it 506 with the server public key to hide it from everyone except the server. 508 Usually the client can safely send data on the underlying transport 509 immediately following the CLIENT_MASTER_KEY message, without waiting 510 for the SERVER_VERIFY; we call this "initial data". Sending initial 511 data is good because it means that PCT adds only one round trip; it is 512 not possible to do better without exposing the server to a replay 513 attack. However, it is unwise to send initial data if for some reason 514 it is important for the client to be sure of being in contact with the 515 correct server before sending any data. 517 5.2 PCT Handshake Protocol Messages 519 The PCT Handshake Protocol messages are sent using the PCT Record 520 Protocol and consist of a single byte message type code, followed by 521 some data. The client and server exchange messages as described 522 above, sending either one or two messages each. Once the handshake 523 has been completed successfully, the client sends its first actual 524 data. 526 Handshake protocol messages are sent in the clear, with the exception 527 of the key-exchange-related fields in the CLIENT_MASTER_KEY message, 528 some of which involve (public-key) encryption. 530 The following notation is used for PCT messages: 532 char MSG_EXAMPLE 533 char FIELD1 534 char FIELD2 535 char THING_LENGTH_MSB 536 char THING_LENGTH_LSB 537 char THING_DATA[(MSB << 8)|LSB]; 538 ... 540 This notation defines the data in the protocol message, including the 541 message type code. The order is presented top to bottom, with the 542 topmost element being transmitted first. 544 For the "THING_DATA" entry, the MSB and LSB values are actually 545 THING_LENGTH_MSB and THING_LENGTH_LSB (respectively) and define the 546 number of bytes of data actually present in the message. For example, 547 if THING_LENGTH_MSB were one and THING_LENGTH_LSB were four then the 548 THING_DATA array would be exactly 260 bytes long. This shorthand is 549 used below. Occasionally, a "THING_DATA" field is referred to as 550 "THING", with the word "DATA" omitted. 552 The names of message elements have prefixes that identify the messages 553 in which they appear; these prefixes are sometimes omitted in the text 554 when the containing messages are obvious. 556 Length codes are unsigned values, and when the MSB and LSB are 557 combined the result is an unsigned value. Length values are in bytes. 559 5.2.1 CLIENT_HELLO (Sent in the clear) 561 char CH_MSG_CLIENT_HELLO 562 char CH_CLIENT_VERSION_MSB 563 char CH_CLIENT_VERSION_LSB 564 char CH_PAD 565 char CH_SESSION_ID_DATA[32] 566 char CH_CHALLENGE_DATA[32] 567 char CH_OFFSET_MSB 568 char CH_OFFSET_LSB 569 char CH_CIPHER_SPECS_LENGTH_MSB 570 char CH_CIPHER_SPECS_LENGTH_LSB 571 char CH_HASH_SPECS_LENGTH_MSB 572 char CH_HASH_SPECS_LENGTH_LSB 573 char CH_CERT_SPECS_LENGTH_MSB 574 char CH_CERT_SPECS_LENGTH_LSB 575 char CH_EXCH_SPECS_LENGTH_MSB 576 char CH_EXCH_SPECS_LENGTH_LSB 577 char CH_KEY_ARG_LENGTH_MSB 578 char CH_KEY_ARG_LENGTH_LSB 579 char CH_CIPHER_SPECS_DATA[(MSB << 8)|LSB] 580 char CH_HASH_SPECS_DATA[(MSB << 8)|LSB] 581 char CH_CERT_SPECS_DATA[(MSB << 8)|LSB] 582 char CH_EXCH_SPECS_DATA[(MSB << 8)|LSB] 583 char CH_KEY_ARG_DATA[(MSB << 8)|LSB] 585 When a client first connects to a server it is required to send the 586 CLIENT_HELLO message. The server is expecting this message from the 587 client as its first message. It is an ILLEGAL_MESSAGE error for a 588 client to send anything else as its first message. The CLIENT_HELLO 589 message begins with the PCT version number, and two fixed-length 590 fields followed by an offset to the variable length data. The 591 CH_OFFSET field contains the number of bytes used by the various 592 fields (currently only length fields) that follow the offset field and 593 precede the variable-length fields. For PCT version 1, this offset 594 value is always PCT_CH_OFFSET_V1, i.e., ten. However, inclusion of 595 this field will allow future versions to be compatible with version 1, 596 even if the number of these fields changes: a version 1 server should 597 be able to find all the PCT version 1 fields in a higher-version 598 CLIENT_HELLO message. The CH_PAD field may contain any value. 600 The CLIENT_HELLO message includes a string of random bytes used as 601 challenge data from the client. Also, if the client finds a session 602 identifier in its cache for the server, then that session-identifier 603 data is sent. Otherwise, the special PCT_SESSION_ID_NONE value is 604 used. In either case, the client specifies in CIPHER_SPECS_DATA, 605 HASH_SPECS_DATA, CERT_SPECS_DATA, and EXCH_SPECS_DATA its preferred 606 choices of symmetric cipher, key lengths, hash function, certificate, 607 and asymmetric key exchange algorithm. However, if a session 608 identifier is sent, then these choices are only relevant in the case 609 where the server cannot recognize the session identifier, and a new 610 session must therefore be initiated. If the server recognizes the 611 session, then these fields are ignored by the server. 613 The CHALLENGE_DATA field contains 32 bytes of random bits, to be used 614 to authenticate the server. The CHALLENGE_DATA should be 615 cryptographically random, in the same sense as the MASTER_KEY (see 616 section 5.3.1). 618 The CIPHER_SPECS_DATA field contains a list of possible symmetric 619 ciphers supported by the client, in order of (the client's) 620 preference. Each element in the list is a four-byte field, of which 621 the first two bytes contain a code representing a cipher type, the 622 third byte contains the encryption key length in bits (0-255), and the 623 fourth byte contains the MAC key length in bits, minus 64 (values 624 0-255, representing lengths 64-319; this encoding enforces the 625 requirement that the MAC key length be at least 64 bits). The entire 626 list's length in bytes (four times the number of elements) is placed 627 in CIPHER_SPECS_LENGTH. 629 The HASH_SPECS_DATA field contains a list of possible hash functions 630 supported by the client, in order of (the client's) preference. The 631 server will choose one of these to be used for computing MACs and 632 deriving keys. Each element in the list is a two-byte field 633 containing a code representing a hash function choice. The entire 634 length of the list (twice the number of elements) is placed in 635 HASH_SPECS_LENGTH. 637 The CERT_SPECS_DATA field contains a list of possible certificate 638 formats supported by the client, in order of (the client's) 639 preference. Each element in the list is a two-byte field containing a 640 code representing a certificate format. The entire length of the list 641 (twice the number of elements) is placed in CERT_SPECS_LENGTH. 643 The EXCH_SPECS_DATA field contains a list of possible asymmetric key 644 exchange algorithms supported by the client, in order of (the 645 client's) preference. Each element in the list is a two-byte field 646 containing a code representing a key exchange algorithm type. The 647 entire length of the list (twice the number of elements) is placed in 648 EXCH_SPECS_LENGTH. 650 The KEY_ARG_DATA field contains an initialization vector to be used in 651 a reconnected session when the cipher type is a block cipher (any 652 cipher type except PCT_CIPHER_RC4, and any key exchange type except 653 PCT_EXCH_RSA_PKCS1_TOKEN_RC4). If a new session is being requested 654 (i.e., the value of CH_SESSION_ID_DATA is PCT_SESSION_ID_NONE), then 655 KEY_ARG_LENGTH must be zero. 657 The CLIENT_HELLO message must be the first message sent by the client 658 to the server. After the message is sent the client waits for a 659 SERVER_HELLO message. Any other message returned by the server (other 660 than ERROR) generates the PCT_ERR_ILLEGAL_MESSAGE error. 662 The server, on receiving a CLIENT_HELLO message, checks the version 663 number and the offset field to determine where the variable-length 664 data fields start. (The OFFSET value should be at least 665 PCT_CH_OFFSET_V1.) The server then checks whether there is a non-null 666 SESSION_ID field, and if so, whether it recognizes the SESSION_ID. In 667 that case, the server responds with a SERVER_HELLO message containing 668 a non-zero RESTART_SESSION_OK field, and the appropriate value (see 669 below) in the RESPONSE and CONNECTION_ID fields. Otherwise, it checks 670 whether the CIPHER_SPECS, HASH_SPECS, CERT_SPECS and EXCH_SPECS lists 671 in the CLIENT_HELLO message each contain at least one type supported 672 by the server. If so, then the server sends a SERVER_HELLO message to 673 the client as described below; otherwise, the server detects a 674 SPECS_MISMATCH error. 676 5.2.2 SERVER_HELLO (Sent in the clear) 678 char SH_MSG_SERVER_HELLO 679 char SH_PAD 680 char SH_SERVER_VERSION_MSB 681 char SH_SERVER_VERSION_LSB 682 char SH_RESTART_SESSION_OK 683 char SH_CLIENT_AUTH_REQ 684 char SH_CIPHER_SPECS_DATA[4] 685 char SH_HASH_SPECS_DATA[2] 686 char SH_CERT_SPECS_DATA[2] 687 char SH_EXCH_SPECS_DATA[2] 688 char SH_CONNECTION_ID_DATA[32] 689 char SH_CERTIFICATE_LENGTH_MSB 690 char SH_CERTIFICATE_LENGTH_LSB 691 char SH_CLIENT_CERT_SPECS_LENGTH_MSB 692 char SH_CLIENT_CERT_SPECS_LENGTH_LSB 693 char SH_CLIENT_SIG_SPECS_LENGTH_MSB 694 char SH_CLIENT_SIG_SPECS_LENGTH_LSB 695 char SH_RESPONSE_LENGTH_MSB 696 char SH_RESPONSE_LENGTH_LSB 697 char SH_CERTIFICATE_DATA[(MSB << 8)|LSB] 698 char SH_CLIENT_CERT_SPECS_DATA[(MSB << 8)|LSB] 699 char SH_CLIENT_SIG_SPECS_DATA[(MSB << 8)|LSB] 700 char SH_RESPONSE_DATA[(MSB << 8)|LSB] 702 The server sends this message after receiving the client's 703 CLIENT_HELLO message. The PCT version number in SH_SERVER_VERSION is 704 always the maximum protocol version that the server supports; the 705 remainder of the message and all subsequent messages will conform to 706 the format specified by the protocol version corresponding to the 707 minimum of the client and server protocol version numbers. Unless 708 there is an error, the server always returns a random value 32 bytes 709 in length in the CONNECTION_ID field. This value doubles as challenge 710 data if the server requests client authentication, and should 711 therefore be random in the same sense as the challenge data in the 712 CLIENT_HELLO message. The SH_PAD field may contain any value. 714 There are two cases for RESTART_SESSION_OK. In the first case, the 715 server returns a zero RESTART_SESSION_OK flag because the CLIENT_HELLO 716 message did not contain a session id or because the one it contained 717 is unrecognized by the server. In this case, the server must behave 718 as follows: 720 The server selects any choice with which it is compatible, from each 721 of the CH_CIPHER_SPECS, CH_HASH_SPECS, CH_CERT_SPECS and CH_EXCH_SPECS 722 lists supplied in the CLIENT_HELLO message. (These values are 723 returned to the client in the SH_CIPHER_SPECS_DATA, 724 SH_HASH_SPECS_DATA, SH_CERT_SPECS_DATA, and SH_EXCH_SPECS_DATA fields, 725 respectively.) The certificate of the type specified in 726 SH_CERT_SPECS_DATA and SH_EXCH_SPECS_DATA is placed in the 727 CERTIFICATE_DATA field. The SH_RESPONSE_DATA field is empty, and its 728 length is zero. 730 In the second case, the server returns a non-zero RESTART_SESSION_OK 731 flag because the CLIENT_HELLO message contained a session-identifier 732 known by the server (i.e. in the server's session-identifier cache). 733 In this case, the server must behave as follows: 735 The server omits the CERTIFICATE_DATA field (with CERTIFICATE_LENGTH 736 set to zero), and sets the CIPHER_SPECS_DATA, HASH_SPECS_DATA, 737 CERT_SPECS_DATA and EXCH_SPECS_DATA values to the values stored along 738 with the session identifier. There are two subcases: (1) If the 739 SH_EXCH_SPECS_DATA does not refer to a TOKEN type, then the 740 CLIENT_MAC, SERVER_MAC, CLIENT_WRITE, and SERVER_WRITE keys are 741 rederived using the MASTER_KEY from the old session, as well as the 742 CONNECTION_ID and CH_CHALLENGE values from the SERVER_HELLO and 743 CLIENT_HELLO messages, respectively, for this connection. (2) If the 744 SH_EXCH_SPECS_DATA refers to a TOKEN type, then the keys from the 745 on-going session are reused. In order to obtain fresh key material or 746 change the sequence number, TOKEN implementations must use the redo 747 handshake mechanism (PCT_ET_REDO_CONN security escape). When this 748 mechanism is used with a TOKEN exchange type, the client must send 749 PCT_SESSION_ID_NONE in the CH_SESSION_ID_DATA field of the subsequent 750 CLIENT_HELLO message. 752 The RESPONSE_DATA is constructed by computing the function 754 Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 755 SH_CONNECTION_ID_DATA, CH_SESSION_ID_DATA ) ). 757 The CH_CHALLENGE_DATA and CH_SESSION_ID_DATA values are found in the 758 CLIENT_HELLO message for this connection. The SH_CONNECTION_ID_DATA 759 value is from this SERVER_HELLO message. The SERVER_MAC_KEY is the 760 one rederived for this connection as described in section 5.3.1. If 761 the length of SERVER_MAC_KEY is not an exact multiple of eight bits, 762 then SERVER_MAC_KEY is considered, for the purposes of MAC 763 computation, to have (fewer than eight) zero bits appended to it, to 764 create a string of an integral number of bytes for input into the MAC 765 hash function. The hash function choice used is determined by the 766 SH_HASH_SPECS_DATA field in this SERVER_HELLO message. The values are 767 input into the interior invocation of the hash function in the exact 768 order specified above, with the string in quotation marks representing 769 actual ASCII text. 771 In both reconnection cases, if the server requires client 772 authentication, then the CLIENT_AUTH_REQ field is set to a non-zero 773 value. Also, a list of (client) certificate types acceptable to the 774 server, in order of (the server's) preference, is placed in the 775 CLIENT_CERT_SPECS_DATA field, and a list of (client's) signature 776 algorithms supported by the server, in order of (the server's) 777 preference, is placed in the CLIENT_SIG_SPECS_DATA field. The 778 certificate type values in the list are from the same set of two byte 779 codes used for the CERT_SPECS list appearing in the CLIENT_HELLO 780 message, and the signature algorithm type codes are also two bytes 781 long. (See section 5.3.4 and 5.3.5 below.) The lengths of the lists 782 in bytes (twice the number of elements) are placed in the 783 CLIENT_CERT_SPECS_LENGTH and CLIENT_SIG_SPECS_LENGTH fields. If no 784 client authentication is required, then these length fields, as well 785 as the CLIENT_AUTH_REQ field, are set to zero, and the corresponding 786 data fields are empty. 788 When the client receives a SERVER_HELLO message, it checks whether the 789 server has accepted a reconnection of an old session or is 790 establishing a new session. If a new session is being initiated, and 791 client authentication is requested, then the client checks whether it 792 is compatible with any of the certificate and signature types listed 793 in the CLIENT_CERT_SPECS and CLIENT_SIG_SPECS lists. (Note that the 794 server can make client authentication optional for the client simply 795 by including PCT_CERT_NONE and PCT_SIG_NONE as a "last resort".) If 796 the client can provide a compatible certificate, then it sends a 797 CLIENT_MASTER_KEY message as described below; otherwise, it generates 798 a SPECS_MISMATCH error. 800 If the session is an old one, then the client establishes the new 801 CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and SERVER_MAC_KEY 802 according to the cipher-specific rules described below in section 803 5.3.1. The client then checks the contents of the RESPONSE_DATA field 804 in the SERVER_HELLO message for correctness. If the response matches 805 the value calculated by the client (exactly as described above for the 806 server), then the handshake is finished, and the client begins sending 807 data; otherwise, a SERVER_AUTH_FAILED error occurs. 809 5.2.3 CLIENT_MASTER_KEY (sent in the clear, except for encrypted keys) 811 char CMK_MSG_CLIENT_MASTER_KEY 812 char CMK_PAD 813 char CMK_CLIENT_CERT_SPECS_DATA[2] 814 char CMK_CLIENT_SIG_SPECS_DATA[2] 815 char CMK_CLEAR_KEY_LENGTH_MSB 816 char CMK_CLEAR_KEY_LENGTH_LSB 817 char CMK_ENCRYPTED_KEY_LENGTH_MSB 818 char CMK_ENCRYPTED_KEY_LENGTH_LSB 819 char CMK_KEY_ARG_LENGTH_MSB 820 char CMK_KEY_ARG_LENGTH_LSB 821 char CMK_VERIFY_PRELUDE_LENGTH_MSB 822 char CMK_VERIFY_PRELUDE_LENGTH_LSB 823 char CMK_CLIENT_CERT_LENGTH_MSB 824 char CMK_CLIENT_CERT_LENGTH_LSB 825 char CMK_RESPONSE_LENGTH_MSB 826 char CMK_RESPONSE_LENGTH_LSB 827 char CMK_CLEAR_KEY_DATA[(MSB << 8)|LSB] 828 char CMK_ENCRYPTED_KEY_DATA[(MSB << 8)|LSB] 829 char CMK_KEY_ARG_DATA[(MSB << 8)|LSB] 830 char CMK_VERIFY_PRELUDE_DATA[(MSB << 8)|LSB] 831 char CMK_CLIENT_CERT_DATA[(MSB << 8)|LSB] 832 char CMK_RESPONSE_DATA[(MSB << 8)|LSB] 834 The client sends this message after receiving the SERVER_HELLO message 835 from the server if a new session is being started or if client 836 authentication has been requested. If no client authentication has 837 been requested in the SERVER_HELLO message and an old session is being 838 reconnected (i.e., if the CLIENT_AUTH_REQ field is zero and the 839 RESTART_SESSION_OK field is nonzero), then the CLIENT_MASTER_KEY 840 message is not sent. 842 For TOKEN exchange types, both client and server (re)set the sequence 843 numbers to zero when this message is sent/received. 845 The contents of the CLEAR_KEY_DATA, ENCRYPTED_KEY_DATA, and 846 KEY_ARG_DATA fields depend on the contents of the SH_CIPHER_SPECS_DATA 847 and SH_EXCH_SPECS_DATA fields in the preceding SERVER_HELLO message. 848 These will be described for each possible choice of these values in 849 section 5.3.1 and 5.3.2, along with how the various keys 850 (CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY, and 851 SERVER_MAC_KEY) are derived in each case. The CMK_PAD field may 852 contain any value. 854 The CMK_VERIFY_PRELUDE_DATA field contains the value 856 Hash( CLIENT_MAC_KEY, Hash( "cvp", CLIENT_HELLO, SERVER_HELLO ) ). 858 If the length of CLIENT_MAC_KEY is not an exact multiple of eight 859 bits, then CLIENT_MAC_KEY is considered, for the purposes of MAC 860 computation, to have (fewer than eight) zero bits appended to it, to 861 create a string of an integral number of bytes for input into the MAC 862 hash function. The hash function used is the one specified in 863 SH_HASH_SPECS_DATA. The parameters are input into the hash function 864 in the order presented above, with the strings in quotation marks 865 representing ASCII text. Note that the client need only keep a 866 "running hash" of all the values passed in these first two messages as 867 they appear, then hash the result using the CLIENT_MAC_KEY when 868 generated, to compute the value of VERIFY_PRELUDE. 870 If SH_CLIENT_AUTH_REQ is zero, then CMK_CLIENT_CERT_SPECS_DATA and 871 CMK_CLIENT_SIG_SPECS_DATA are both zero, and the CMK_CLIENT_CERT and 872 CMK_RESPONSE_DATA fields are empty. Otherwise, the CMK_RESPONSE_DATA 873 field contains the client's authentication response, and the 874 CMK_CLIENT_CERT_SPECS_DATA and CMK_CLIENT_SIG_SPECS_DATA fields 875 contain the client's choices from the SH_CLIENT_CERT_SPECS_DATA and 876 SH_CLIENT_SIG_SPECS_DATA lists, respectively. The 877 CMK_CLIENT_CERT_DATA field contains the client's certificate, which 878 must match the certificate type specified in the 879 CMK_CLIENT_CERT_SPECS_DATA field. Also, the public key in the 880 certificate must be a signature key of the type specified in 881 CMK_CLIENT_SIG_SPECS_DATA, which in turn must match one of the types 882 in the SH_CLIENT_SIG_SPECS_DATA list. 884 CMK_RESPONSE_DATA is simply a digital signature, using the private 885 signature key associated with the public key in the client's 886 certificate, of the value in the CMK_VERIFY_PRELUDE_DATA field. The 887 signature algorithm is determined by the CMK_CLIENT_SIG_SPECS_DATA 888 field. (Note that the signature algorithm may itself require that a 889 hash function be applied to the data being signed, apart from the one 890 used to compute the value in CMK_VERIFY_PRELUDE_DATA.) 892 Upon receiving a CLIENT_MASTER_KEY message, the server performs the 893 cipher-specific functions described in section 5.3 to establish the 894 new CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and 895 SERVER_MAC_KEY. The server then checks the VERIFY_PRELUDE_DATA value, 896 the client certificate, and the client response for correctness and 897 validity (the latter two only if client authentication had been 898 requested). The checks of the VERIFY_PRELUDE_DATA and RESPONSE_DATA 899 are performed by recomputing their correct value, and comparing with 900 the values received. The certificate is verified using whatever 901 mechanism has been implemented to validate certificates, and the 902 signature in the RESPONSE_DATA field is verified using the 903 verification algorithm associated with the signature scheme being 904 used. If all of these values pass their checks, then the server sends 905 the SERVER_VERIFY message; otherwise, an error occurs 906 (INTEGRITY_CHECK_FAILED, BAD_CERTIFICATE, or CLIENT_AUTH_FAILED, 907 respectively). 909 5.2.4 SERVER_VERIFY (Sent in the clear) 911 char SV_MSG_SERVER_VERIFY 912 char SV_PAD 913 char SV_SESSION_ID_DATA[32] 914 char SV_RESPONSE_LENGTH_MSB 915 char SV_RESPONSE_LENGTH_LSB 916 char SV_RESPONSE_DATA[(MSB << 8)|LSB] 918 The server sends this message upon receiving a valid CLIENT_MASTER_KEY 919 message from the client. The SV_PAD field may contain any value. If 920 an old session is being reconnected, then the RESPONSE_DATA field is 921 empty, its length is zero, and the SESSION_ID_DATA field may contain 922 any value. Otherwise, the SV_SESSION_ID_DATA field contains a value 923 32 bytes in length, which should be generated randomly (in the same 924 sense as the CHALLENGE_DATA field in the CLIENT_HELLO message). The 925 value PCT_SESSION_ID_NONE should not be used as a SV_SESSION_ID_DATA 926 value. The contents of the SV_RESPONSE_DATA field are constructed by 927 computing the function 929 Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 930 SH_CONNECTION_ID_DATA, SV_SESSION_ID_DATA ) ). 932 The CH_CHALLENGE_DATA and SH_CONNECTION_ID_DATA values, the choice of 933 hash function used, and the value of SERVER_MAC_KEY are determined by 934 the CLIENT_HELLO, SERVER_HELLO, SERVER_HELLO and CLIENT_MASTER_KEY 935 messages, respectively, immediately preceding the SERVER_VERIFY 936 message. The values are input into the interior invocation of the 937 hash function in the exact order specified above, with the string in 938 quotation marks representing actual ASCII text. If the length of 939 SERVER_MAC_KEY is not an exact multiple of eight bits, then 940 SERVER_MAC_KEY is considered, for the purposes of MAC computation, to 941 have (fewer than eight) zero bits appended to it, to create a string 942 of an integral number of bytes for intput into the MAC hash function. 944 When the client receives this message, it verifies the correctness of 945 the response data, by computing the hash value as described above and 946 comparing it with the one received. If it is correct, then the client 947 proceeds with the first data record transmission; otherwise, a 948 SERVER_AUTH_FAILED error occurs. An implementation may choose to send 949 initial data immediately after the CLIENT_MASTER_KEY message, without 950 waiting for the SERVER_VERIFY message to arrive, if verifying the 951 server's identity before sending it any data is unimportant. 953 5.3 Algorithm and Certificate Types 955 5.3.1 Key Exchange Algorithms 957 PCT version 1 permits the following key exchange types: 959 PCT_EXCH_RSA_PKCS1 960 PCT_EXCH_RSA_PKCS1_TOKEN_DES 961 PCT_EXCH_RSA_PKCS1_TOKEN_DES3 962 PCT_EXCH_RSA_PKCS1_TOKEN_RC2 963 PCT_EXCH_RSA_PKCS1_TOKEN_RC4 964 PCT_EXCH_DH_PKCS3 965 PCT_EXCH_DH_PKCS3_TOKEN_DES 966 PCT_EXCH_DH_PKCS3_TOKEN_DES3 967 PCT_EXCH_FORTEZZA_TOKEN 969 Note that the token-based key exchange types specify cipher as well 970 (including, implicitly, the FORTEZZA key exchange type); if one of 971 these is chosen, then its choice of cipher overrides whatever choice 972 of cipher appears in the SH_CIPHER_SPECS_DATA field of the 973 SERVER_HELLO message. 975 For the PCT_EXCH_RSA_PKCS1 key exchange type, a MASTER_KEY value is 976 generated by the client, which should be random in the following 977 strong sense: attackers must not be able to predict any of the bits in 978 the MASTER_KEY. It is recommended that the bits used be either truly 979 random and uniformly generated (using some random physical process) or 980 else generated using a cryptographically secure pseudorandom number 981 generator, which was in turn seeded with a truly random and uniformly 982 generated seed. This MASTER_KEY value is encrypted using the server's 983 public encryption key, as obtained from the server's certificate in 984 the SH_CERTIFICATE_DATA field of the SERVER_HELLO message. The 985 encryption must follow the RSA PKCS#1 standard format (see [2]), block 986 type 2. This encryption is sent to the server in the 987 CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message, and is 988 decrypted by the server to obtain the MASTER_KEY. 990 For the PCT_EXCH_DH_PKCS3 key exchange type, a random private value x 991 (generated in the same way as the MASTER_KEY above) and corresponding 992 public value y are generated by the client following RSA PKCS#3 993 standard format (see [3]). The value y is then sent to the server in 994 the CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message. 995 The client's private value x, along with the public value y' included 996 in the server's certificate in the SH_CERTIFICATE_DATA field of the 997 SERVER_HELLO message, is used to generate the MASTER_KEY. The server 998 uses its private value, x', along with the y value sent by the client, 999 to obtain the same MASTER_KEY value. 1001 For the various TOKEN key exchange types, all the key material is 1002 contained in the CMK_ENCRYPTED_KEY_DATA field, but the format of the 1003 data is defined by the token implementation, or by other future 1004 documents. 1006 The length of the MASTER_KEY depends on the key exchange type. For 1007 the PCT_EXCH_RSA_PKCS1 and PCT_EXCH_DH_PKCS3 exchange types, the 1008 MASTER_KEY is a 128-bit value. The CLIENT_WRITE_KEY and 1009 SERVER_WRITE_KEY are computed as follows: 1011 CLIENT_WRITE_KEY_i = Hash( i, "cw", MASTER_KEY, "cw"^i, 1012 SH_CONNECTION_ID_DATA, "cw"^i, SH_CERTIFICATE_DATA,"cw"^i, 1013 CH_CHALLENGE_DATA, "cw"^i ) 1015 SERVER_WRITE_KEY_i = Hash( i, "svw", MASTER_KEY, "svw"^i, 1016 SH_CONNECTION_ID_DATA, "svw"^i, CH_CHALLENGE_DATA, "svw"^i ) 1018 The values in quotation marks are treated as (sequences of) ASCII 1019 characters; "x"^i denotes i copies of the string "x" concatenated 1020 together. The function "Hash" is the one determined by the value of 1021 SH_HASH_SPECS_DATA. The parameters are input into the hash function 1022 in the order presented above; the variable i is input as a single-byte 1023 unsigned integer. The WRITE_KEYs (i.e., CLIENT_WRITE_KEY and 1024 SERVER_WRITE_KEY) are obtained by concatenating WRITE_KEY_1 through 1025 WRITE_KEY_m, where m is the negotiated encryption key length (the 1026 value in the third byte of the SH_CIPHER_SPECS_DATA field) divided by 1027 the hash output length, in bits, rounded up to the nearest integer. 1028 This resulting string is then truncated if necessary (by removing bits 1029 from the end) to produce a string of the correct length. 1031 The CLIENT_MAC_KEY and SERVER_MAC_KEY are computed as follows: 1033 CLIENT_MAC_KEY_i = Hash( i, MASTER_KEY, "cmac"^i, 1034 SH_CONNECTION_ID_DATA, "cmac"^i, SH_CERTIFICATE_DATA, "cmac"^i, 1035 CH_CHALLENGE_DATA, "cmac"^i ) 1037 SERVER_MAC_KEY_i = Hash( i, MASTER_KEY, "svmac"^i, 1038 SH_CONNECTION_ID_DATA, "svmac"^i, CH_CHALLENGE_DATA, "svmac"^i ) 1040 The values in quotation marks are treated as (sequences of) ASCII 1041 characters; "x"^i denotes i copies of the string "x" concatenated 1042 together. The function "Hash" is the one determined by the value of 1043 SH_HASH_SPECS_DATA. The parameters are input into the hash function 1044 in the order presented above; the variable i is input as a single-byte 1045 unsigned integer. The MAC_KEYs (ie., CLIENT_MAC_KEY and 1046 SERVER_MAC_KEY) are obtained by concatenating MAC_KEY_1 through 1047 MAC_KEY_m, where m is the negotiated MAC key length (64 plus the value 1048 in the fourth byte of the SH_CIPHER_SPECS_DATA field) divided by the 1049 hash output length, in bits, rounded up to the nearest integer. This 1050 resulting string is then truncated if necessary (by removing bits from 1051 the end) to produce a string of the correct length. 1053 Note that tokens which are capable of deriving keys using "keyed 1054 hashes", as described above, are free to use the PCT_EXCH_RSA_PKCS1 1055 or PCT_EXCH_DH_PKCS3 key exchange type to exchange the MASTER_KEY, 1056 and then to derive the rest of the keys normally. The TOKEN key 1057 exchange types are for tokens that cannot do such keyed-hash key 1058 derivation, and can only use an exchanged key for bulk encryption 1059 (of, for example, other keys). Such tokens can exchange multiple 1060 keys by using an initially exchanged MASTER_KEY to encrypt other 1061 keys, as described above. 1063 5.3.2 Cipher Types 1065 PCT version 1 permits the following cipher types to be specified: 1067 PCT_CIPHER_DES 1068 PCT_CIPHER_IDEA 1069 PCT_CIPHER_RC2 1070 PCT_CIPHER_RC4 1071 PCT_CIPHER_DES_112 1072 PCT_CIPHER_DES_168 1074 Each of these types is denoted by a two-byte code, and is followed in 1075 CIPHER_SPECS_DATA fields by two one-byte length specifications, as 1076 described in section 5.2.1. An encryption length specification of 1077 zero associated with any cipher denotes the choice of no encryption; a 1078 key exchange is performed in such cases solely to share keys for MAC 1079 computation. The MAC key length must always be at least 64 bits (see 1080 section 5.2.1). 1082 The CLEAR_KEY_DATA field is used only when encryption keys of length 1083 less than the standard length for the specified cipher are used; 1084 otherwise, the field is empty. When a key length is specified which 1085 is less than the standard key length for the specified cipher, then 1086 keys of the specified length are derived normally as described in 1087 section 5.3.1, and then "expanded" to derive standard-length keys. 1088 The expansion proceeds as follows: 1090 1. Assign to d the result of dividing the standard key length for 1091 the cipher, in bits, by the output length of the hash function, in 1092 bits, rounded up to the nearest integer. 1094 2. Divide CLEAR_KEY_DATA sequentially into d equal subsegments. 1095 (Note that the length of the CLEAR_KEY_DATA field must therefore be a 1096 multiple of d bytes, and that no two of its d equal parts, when so 1097 divided, may be identical.) Denote these subsegments CLEAR_KEY_DATA_1 1098 through CLEAR_KEY_DATA_d. 1100 3. Compute the d hash values 1102 STANDARD_LENGTH_KEY_i := Hash( i, "sl"^i, WRITE_KEY, "sl"^i, 1103 CLEAR_KEY_DATA_i ). 1105 The values in quotation marks are treated as (sequences of) ASCII 1106 characters; "x"^i denotes i copies of the string "x" concatenated 1107 together. The function "Hash" is the one determined by the value of 1108 SH_HASH_SPECS_DATA. The parameters are input into the hash function 1109 in the order presented above; the variable i is input as a 1110 single-byte unsigned integer. The WRITE_KEY is the encryption key 1111 (CLIENT_WRITE_KEY or SERVER_WRITE_KEY) being expanded to standard 1112 length. If the length of the WRITE_KEY is not an exact number of 1113 bytes, then its final byte is padded with zeroes to increase its 1114 length to an exact number of bytes. 1116 4. Concatenate STANDARD_LENGTH_KEY_1 through STANDARD_LENGTH_KEY_d, 1117 and then truncate as necessary (by removing bits from the end) to 1118 produce the STANDARD_LENGTH_KEY which is actually used for encryption. 1120 The KEY_ARG_DATA field contains a random eight-byte value to be used 1121 as an initialization vector (IV) for the first encrypted message when 1122 a block cipher (any cipher except RC4) is used. The IV for the first 1123 block encrypted in any subsequent encrypted message is simply the last 1124 encrypted block of the previous message. The KEY_ARG_DATA field is 1125 empty when cipher type PCT_CIPHER_RC4 (or key exchange type 1126 PCT_EXCH_RSA_PKCS1_TOKEN_RC4) is used. 1128 PCT_CIPHER_DES denotes DES (see [4]). Its standard key length is 56 1129 bits. PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 denote ciphers in 1130 which the input is first encrypted under DES with a first key, then 1131 "decrypted" under DES with a second key, then encrypted under DES with 1132 a third key. For PCT_CIPHER_DES_112, the first and third keys are 1133 identical, and correspond to the initial 56 bits of the 112-bit 1134 WRITE_KEY. The second key corresponds to the final 56 bits of the 1135 WRITE_KEY. For PCT_CIPHER_DES_168, the three keys are distinct, and 1136 correspond to the first, second, and third 56-bit subsegments of the 1137 WRITE_KEY. All three of these DES-based cipher types have 64-bit data 1138 blocks and are used with cipher block chaining (CBC). 1140 The standard key lengths for PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 1141 are 112 bits and 168 bits, respectively. If a key length less than 1142 the standard length is specified for one of these ciphers (or for 1143 PCT_CIPHER_DES), then the WRITE_KEY is expanded to the standard length 1144 as described above. 1146 Note that before use, each 56-bit DES key must be "adjusted" to add 1147 eight parity bits to form an eight-byte DES key (see [4]). Similarly, 1148 if the specified WRITE_KEY length is less than its corresponding 1149 standard length, then each WRITE_KEY is expanded to the standard 1150 length using CLEAR_KEY_DATA as described above, to produce one, two, 1151 or three keys of 56 bits each, which are then each "adjusted" by 1152 adding parity bits to form an eight-byte key. 1154 PCT_CIPHER_IDEA denotes the IDEA block cipher (see [5]), with 64-bit 1155 data blocks and cipher block chaining. This cipher has a standard key 1156 length of 128 bits. 1158 PCT_CIPHER_RC2 denotes the RC2 block cipher, with 64-bit blocks and 1159 cipher block chaining. Like IDEA, this cipher has a standard key 1160 length of 128 bits. 1162 PCT_CIPHER_RC4 denotes the RC4 stream cipher. Like the IDEA and RC2 1163 block ciphers, this cipher has a standard key length of 128 bits. 1165 5.3.3 Hash Types 1167 PCT version 1 permits the following hash function types to be 1168 specified: 1170 PCT_HASH_MD5 1171 PCT_HASH_MD5_TRUNC_64 1172 PCT_HASH_SHA 1173 PCT_HASH_SHA_TRUNC_80 1174 PCT_HASH_DES_DM 1176 PCT_CIPHER_MD5 denotes the MD5 hash function (see [6]), with 128-bit 1177 output. PCT_CIPHER_MD5_TRUNC_64 denotes the MD5 hash function, with 1178 its 128-bit output truncated to 64 bits. PCT_HASH_SHA denotes the 1179 Secure Hash Algorithm (see [7]), with 160-bit output. 1180 PCT_HASH_SHA_TRUNC_80 denotes the Secure Hash Algorithm, with its 1181 160-bit output truncated to 80 bits. PCT_HASH_DES_DM denotes the 1182 DES-based Davies-Meyer hash algorithm (see [8]), with 64-bit output. 1184 5.3.4 Certificate Types 1186 PCT version 1 permits the following certificate types to be specified: 1188 PCT_CERT_NONE 1189 PCT_CERT_X509 1190 PCT_CERT_PKCS7 1191 These types apply equally to the client's and server's certificates. 1192 PCT_CERT_NONE denotes that no certificate is necessary; this type can 1193 be included by, say, the server as a choice, thereby making 1194 authentication optional for the client. PCT_CERT_X509 denotes a 1195 CCITT X.509 standard-conformant certificate (see [9]). 1196 PCT_CERT_PKCS7 denotes an RSA PKCS#7 standard-conformant certificate 1197 (see [10]). 1199 5.3.5 Signature Types 1201 PCT version 1 permits the following signature key types to be 1202 specified: 1204 PCT_SIG_NONE 1205 PCT_SIG_RSA_MD5 1206 PCT_SIG_RSA_SHA 1207 PCT_SIG_DSA_SHA 1209 PCT_SIG_NONE denotes that no signature is necessary; this type can be 1210 included by the server as a choice, thereby making authentication 1211 optional for the client. PCT_SIG_RSA_MD5 denotes the signature scheme 1212 consisting of hashing the data to be signed using the MD5 hash 1213 algorithm, and then performing an RSA private-key signature function 1214 (the inverse of RSA encryption) on the result. The signature must 1215 conform to RSA PKCS#1, block type 1 (see [2]). PCT_SIG_RSA_SHA 1216 denotes the same signature scheme with SHA substituted for MD5. 1217 PCT_SIG_DSA_SHA denotes the signature scheme consisting of hashing the 1218 data to be signed using the SHA hash algorithm, then computing a 1219 signature of the resulting value using the Digital Signature Algorithm 1220 (DSA; see [11]). 1222 5.4 Errors 1224 Error handling in the PCT protocol is very simple. When an error is 1225 detected during the handshake phase, the detecting party sends a 1226 message to the other party indicating the error so that both parties 1227 will know about it, and then closes the connection. If a party 1228 detects an error after it has sent its last handshake message, the 1229 detecting party simply closes the connection without sending an error 1230 message. In the second case there are only two possible errors, and 1231 the party that does not detect the error can distinguish them as 1232 follows: if the server sees an aborted connection and the most recent 1233 message it sent the client was a handshake message, then the error was 1234 SERVER_AUTH_FAILED; otherwise, the error was INTEGRITY_CHECK_FAILED. 1236 Receiving an error message also causes the receiving party to close 1237 the connection. Servers and clients should not make any further use 1238 of any keys, challenges, connection identifiers, or session 1239 identifiers associated with such an aborted connection. 1241 It is recommended that implementations perform some kind of alert or 1242 logging function when errors are generated to facilitate monitoring of 1243 various types of attack on the system. 1245 The message sent in the event of a handshake-phase error has the 1246 following form: 1248 char MSG_ERROR 1249 char ERROR_CODE_MSB 1250 char ERROR_CODE_LSB 1251 char ERROR_INFO_LENGTH_MSB 1252 char ERROR_INFO_LENGTH_LSB 1253 char ERROR_INFO_DATA[(MSB << 8)|LSB] 1255 The ERROR_INFO_LENGTH field is zero except in the case of the 1256 SPECS_MISMATCH error message, which has a six-byte ERROR_INFO_DATA 1257 field. 1259 The PCT Handshake Protocol defines the following errors: 1261 PCT_ERR_BAD_CERTIFICATE 1263 This error occurs when the client receives a SERVER_HELLO message in 1264 which the certificate is invalid, either because one or more of the 1265 signatures in the certificate is invalid, or because the identity or 1266 attributes on the certificate are in some way incorrect. 1268 PCT_ERR_CLIENT_AUTH_FAILED 1270 This error occurs when the server receives a CLIENT_MASTER_KEY message 1271 from the client in which the client's authentication response is 1272 incorrect. The certificate may be invalid, the signature may be 1273 invalid, or the contents of the signed response may be incorrect. 1275 PCT_ERR_ILLEGAL_MESSAGE 1277 This error occurs under a number of circumstances. For example, it 1278 occurs when an unrecognized security escape code is received, when an 1279 unrecognized handshake message is encountered, or when the value of 1280 CH_OFFSET is to large for its CLIENT_HELLO message. 1282 PCT_ERR_INTEGRITY_CHECK_FAILED 1284 This error occurs when either the client or the server receives a 1285 message in which the MAC_DATA is incorrect. It is also recommended 1286 that the record be treated as if it contained no data, in order to 1287 ensure that applications do not receive and process invalid data 1288 before learning that it has failed its integrity check. 1290 This error also occurs when the VERIFY_PRELUDE_DATA value sent by the 1291 client in the CLIENT_MASTER_KEY message (during the handshake phase) 1292 is incorrect. In this case, an error message is sent. 1294 PCT_ERR_SERVER_AUTH_FAILED 1296 This error occurs when the client receives a SERVER_HELLO or 1297 SERVER_VERIFY message in which the authentication response is 1298 incorrect. 1300 PCT_ERR_SPECS_MISMATCH 1302 This error occurs when a server cannot find a cipher, hash function, 1303 certificate type, or key exchange algorithm it supports in the lists 1304 supplied by the client in the CLIENT_HELLO message. It also occurs 1305 when the client cannot find a certificate or signature type it 1306 supports in the list supplied by the server in a SERVER_HELLO message 1307 that requests client authentication. (Note that the client or server 1308 can select the "NONE" option as the last resort for any security 1309 feature it wishes to make optional. For example, the server can make 1310 client authentication optional for the client by passing a list of 1311 certificate and signature types, each list containing the "NONE" type 1312 as the last entry.) This error may also occur as a result of a 1313 mismatch in cipher specifications or client authentication requests 1314 between the initial specifications and those that resulted from a redo 1315 handshake sequence. 1317 The error message for this error includes a six-byte informational 1318 field, defined as follows: 1320 char SPECS_MISMATCH_CIPHER 1321 char SPECS_MISMATCH_HASH 1322 char SPECS_MISMATCH_CERT 1323 char SPECS_MISMATCH_EXCH 1324 char SPECS_MISMATCH_CLIENT_CERT 1325 char SPECS_MISMATCH_CLIENT_SIG 1327 Each field is set to a non-zero value if and only if the corresponding 1328 list resulted in a mismatch. For example, if and only if the 1329 SPECS_MISMATCH error message is being sent because server failed to 1330 find a certificate type it supports in the list supplied by the client 1331 in the CH_CERT_SPECS_DATA field, then the SPECS_MISMATCH_CERT field in 1332 the error message would be non-zero. 1334 5.5 Constants 1336 Following is a list of constant values used in the PCT protocol 1337 version 1. 1339 5.5.1 Message type codes 1341 These codes are each placed in the first byte of the corresponding 1342 PCT handshake phase message. 1344 PCT_MSG_CLIENT_HELLO := 0x01 1345 PCT_MSG_SERVER_HELLO := 0x02 1346 PCT_MSG_CLIENT_MASTER_KEY := 0x03 1347 PCT_MSG_SERVER_VERIFY := 0x04 1348 PCT_MSG_ERROR := 0x05 1350 5.5.2 Specification Type Codes 1352 These are codes used to specify types of cipher, key exchange, hash 1353 function, certificate, and digital signature in the protocol. 1355 PCT_EXCH_RSA_PKCS1 := 0x0001 1356 PCT_EXCH_RSA_PKCS1_TOKEN_DES := 0x0002 1357 PCT_EXCH_RSA_PKCS1_TOKEN_DES3 := 0x0003 1358 PCT_EXCH_RSA_PKCS1_TOKEN_RC2 := 0x0004 1359 PCT_EXCH_RSA_PKCS1_TOKEN_RC4 := 0x0005 1360 PCT_EXCH_DH_PKCS3 := 0x0006 1361 PCT_EXCH_DH_PKCS3_TOKEN_DES := 0x0007 1362 PCT_EXCH_DH_PKCS3_TOKEN_DES3 := 0x0008 1363 PCT_EXCH_FORTEZZA_TOKEN := 0x0009 1365 PCT_CIPHER_DES := 0x0001 1366 PCT_CIPHER_IDEA := 0x0002 1367 PCT_CIPHER_RC2 := 0x0003 1368 PCT_CIPHER_RC4 := 0x0004 1369 PCT_CIPHER_DES_112 := 0x0005 1370 PCT_CIPHER_DES_168 := 0x0006 1372 PCT_HASH_MD5 := 0x0001 1373 PCT_HASH_MD5_TRUNC_64 := 0x0002 1374 PCT_HASH_SHA := 0x0003 1375 PCT_HASH_SHA_TRUNC_80 := 0x0004 1376 PCT_HASH_DES_DM := 0x0005 1378 PCT_CERT_NONE := 0x0000 1379 PCT_CERT_X509 := 0x0001 1380 PCT_CERT_PKCS7 := 0x0002 1382 PCT_SIG_NONE := 0x0000 1383 PCT_SIG_RSA_MD5 := 0x0001 1384 PCT_SIG_RSA_SHA := 0x0002 1385 PCT_SIG_DSA_SHA := 0x0003 1387 5.5.3 Error Codes 1389 These codes are used to identify errors, when they occur, in error 1390 messages. 1392 PCT_ERR_BAD_CERTIFICATE := 0x0001 1393 PCT_ERR_CLIENT_AUTH_FAILED := 0x0002 1394 PCT_ERR_ILLEGAL_MESSAGE := 0x0003 1395 PCT_ERR_INTEGRITY_CHECK_FAILED := 0x0004 1396 PCT_ERR_SERVER_AUTH_FAILED := 0x0005 1397 PCT_ERR_SPECS_MISMATCH := 0x0006 1399 5.5.4 Miscellaneous Codes 1401 These include escape type codes, version numbers, and assorted 1402 constants associated with the PCT protocol. 1404 PCT_SESSION_ID_NONE := 0x00 (32 bytes of zeros) 1406 PCT_ET_OOB_DATA := 0x01 1407 PCT_ET_REDO_CONN := 0x02 1409 PCT_VERSION_1 := 0x8001 1411 PCT_CH_OFFSET_V1 := 0x000A 1413 PCT_MAX_RECORD_LENGTH_2_BYTE_HEADER := 32767 1414 PCT_MAX_RECORD_LENGTH_3_BYTE_HEADER := 16383 1416 6. Security Considerations 1418 This entire document is about security. 1420 References 1422 [1] K. Hickman and T. Elgamal. The SSL Protocol. Internet-draft, 1423 June 1995. 1425 [2] RSA Laboratories, "PKCS #1: RSA Encryption Standard", Version 1426 1.5, November 1993. 1428 [3] RSA Laboratories, "PKCS #3: "Diffie-Hellman Key-Agreement 1429 Standard", Version 1.4, November 1993. 1431 [4] NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of 1432 Standards, US Department of Commerce, Jan. 1977. 1434 [5] X. Lai, "On the Design and Security of Block Ciphers", ETH Series 1435 in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. 1437 [6] R. Rivest, RFC 1321: "The MD5 Message Digest Algorithm", April 1438 1992. 1440 [7] NIST FIPS PUB 180-1, "Secure Hash Standard", National Institute 1441 of Standards and Technology, US Department of Commerce, Apr. 1995. 1443 [8] ISO/IEC 9797, "Data Cryptographic Techniques--Data Integrity 1444 Mechanism Using a Cryptographic Check Function Employing a Block 1445 Cipher Algorithm", 1989. 1447 [9] CCITT. Recommendation X.509: "The Directory - Authentication 1448 Framework". 1988. 1450 [10] RSA Laboratories, "PKCS #7: Cryptographc Message Syntax 1451 Standard", Version 1.5, November 1993. 1453 [11] NIST FIPS PUB 186, "Digital Signature Standard", National 1454 Institute of Standards and Technology, US Department of Commerce, May 1455 1994. 1457 [12] B. Schneier, "Applied Cryptography: Protocols, Algorithms, and 1458 Source Code in C", John Wiley & Sons, Inc., 1994. 1460 [13] R.L. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining 1461 Digital Signatures and Public Key Cryptosystems" MIT Laboratory for 1462 Computer Science and Department of Mathematics, S.L. Graham, 1463 R.L. Rivest ed. Communications of the ACM, February 1978 (Vol 21, 1464 No. 2) pages 120-126. 1466 Patent Statement 1468 This version of the PCT protocol relies on the use of patented public 1469 key encryption technology for authentication and encryption. The 1470 Internet Standards Process as defined in RFC 1310 requires a written 1471 statement from the Patent holder that a license will be made 1472 available to applicants under reasonable terms and conditions prior 1473 to approving a specification as a Proposed, Draft or Internet 1474 Standard. 1476 See existing RFCs, including RFC 1170, that discuss known public key 1477 cryptography patents and licensing terms and conditions. 1479 The Internet Society, Internet Architecture Board, Internet 1480 Engineering Steering Group and the Corporation for National Research 1481 Initiatives take no position on the validity or scope of the patents 1482 and patent applications, nor on the appropriateness of the terms of 1483 the assurance. The Internet Society and other groups mentioned above 1484 have not made any determination as to any other intellectual property 1485 rights which may apply to the practice of this standard. Any further 1486 consideration of these matters is the user's own responsibility. 1488 Author's Address 1490 Josh Benaloh/Butler Lampson/Daniel R. Simon/Terence Spies/Bennet Yee 1491 Microsoft Corp. 1492 One Microsoft Way 1493 Redmond WA 98052 1494 USA 1496 pct@microsoft.com 1498 This Internet-Draft expires 27 March 1996.