diff options
Diffstat (limited to 'doc/protocol/draft-hickman-netscape-ssl-00.txt')
| -rw-r--r-- | doc/protocol/draft-hickman-netscape-ssl-00.txt | 1510 |
1 files changed, 0 insertions, 1510 deletions
diff --git a/doc/protocol/draft-hickman-netscape-ssl-00.txt b/doc/protocol/draft-hickman-netscape-ssl-00.txt deleted file mode 100644 index 5658bdff89..0000000000 --- a/doc/protocol/draft-hickman-netscape-ssl-00.txt +++ /dev/null @@ -1,1510 +0,0 @@ - - Kipp E.B. Hickman -Internet Draft Netscape Communications Corp - April 1995 (Expires 10/95) - - The SSL Protocol - <draft-hickman-netscape-ssl-00.txt> - -1. STATUS OF THIS MEMO - -This document is an Internet-Draft.Internet-Drafts are working documents -of the Internet Engineering Task Force (IETF), its areas, and its working -groups. Note that other groups may also distribute working documents as -Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material or to -cite them other than as "work in progress." - -To learn the current status of any Internet-Draft, please check the "1id- -abstracts.txt" listing contained in the Internet- Drafts Shadow Directories -on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US -West Coast), or munnari.oz.au (Pacific Rim). -2. ABSTRACT - -This document specifies the Secure Sockets Layer (SSL) protocol, a -security protocol that provides privacy over the Internet. The protocol -allows client/server applications to communicate in a way that cannot be -eavesdropped. Server's are always authenticated and clients are optionally -authenticated. - -3. INTRODUCTION - -The SSL Protocol is designed to provide privacy between two -communicating applications (a client and a server). Second, the protocol is -designed to authenticate the server, and optionally the client. SSL requires -a reliable transport protocol (e.g. TCP) for data transmission and -reception. - -The advantage of the SSL Protocol is that it is application protocol -independent. A "higher level" application protocol (e.g. HTTP, FTP, -TELNET, etc.) can layer on top of the SSL Protocol transparently. The -SSL Protocol can negotiate an encryption algorithm and session key as -well as authenticate a server before the application protocol transmits or -receives its first byte of data. All of the application protocol data is -transmitted encrypted, ensuring privacy. - -The SSL protocol provides "channel security" which has three basic -properties: - - The channel is private. Encryption is used for all messages after a -simple handshake is used to define a secret key. Symmetric -cryptography is used for data encryption (e.g. DES, RC4, etc.) - - The channel is authenticated. The server endpoint of the conversation -is always authenticated, while the client endpoint is optionally -authenticated. Asymmetric cryptography is used for authentication - -Hickman [page 1] - -(e.g. Public Key Cryptography). - - The channel is reliable. The message transport includes a message -integrity check (using a MAC). Secure hash functions (e.g. MD2, -MD5) are used for MAC computations. - -The SSL protocol is actually composed of two protocols. At the lowest -level, layered on top of some reliable transport protocol, is the "SSL -Record Protocol". The SSL Record Protocol is used for encapsulation of -all transmitted and received data, including the SSL Handshake Protocol, -which is used to establish security parameters. -4. SSL Record Protocol Specification - -4.1 SSL Record Header Format - -In SSL, all data sent is encapsulated in a record, an object which is -composed of a header and some non-zero amount of data. Each record -header contains a two or three byte length code. If the most significant bit -is set in the first byte of the record length code then the record has no -padding and the total header length will be 2 bytes, otherwise the record -has padding and the total header length will be 3 bytes. The record header -is transmitted before the data portion of the record. - -Note that in the long header case (3 bytes total), the second most -significant bit in the first byte has special meaning. When zero, the record -being sent is a data record. When one, the record being sent is a security -escape (there are currently no examples of security escapes; this is -reserved for future versions of the protocol). In either case, the length code -describes how much data is in the record. - -The record length code does not include the number of bytes consumed by -the record header (2 or 3). For the 2 byte header, the record length is -computed by (using a "C"-like notation): - -RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1]; - -Where byte[0] represents the first byte received and byte[1] the second -byte received. When the 3 byte header is used, the record length is -computed as follows (using a "C"-like notation): - -RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1]; -IS-ESCAPE = (byte[0] & 0x40) != 0; -PADDING = byte[2]; - -The record header defines a value called PADDING. The PADDING -value specifies how many bytes of data were appended to the original -record by the sender. The padding data is used to make the record length -be a multiple of the block ciphers block size when a block cipher is used -for encryption. - -The sender of a "padded" record appends the padding data to the end of its -normal data and then encrypts the total amount (which is now a multiple -of the block cipher's block size). The actual value of the padding data is -unimportant, but the encrypted form of it must be transmitted for the -receiver to properly decrypt the record. Once the total amount being - -Hickman [page 2] - -transmitted is known the header can be properly constructed with the -PADDING value set appropriately. - -The receiver of a padded record decrypts the entire record data (sans -record length and the optional padding) to get the clear data, then subtracts -the PADDING value from the RECORD-LENGTH to determine the -final RECORD-LENGTH. The clear form of the padding data must be -discarded. - -4.1.1 SSL Record Data Format - -The data portion of an SSL record is composed of three components -(transmitted and received in the order shown): - -MAC-DATA[MAC-SIZE] -ACTUAL-DATA[N] -PADDING-DATA[PADDING] - -ACTUAL-DATA is the actual data being transmitted (the message -payload). PADDING-DATA is the padding data sent when a block cipher -is used and padding is needed. Finally, MAC-DATA is the "Message -Authentication Code". - -When SSL records are sent in the clear, no cipher is used.Consequently the -amount of PADDING-DATA will be zero and the amount of MAC- -DATA will be zero. When encryption is in effect, the PADDING-DATA -will be a function of the cipher block size. The MAC-DATA is a function -of the CIPHER-CHOICE (more about that later). - -The MAC-DATA is computed as follows: - -MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, -SEQUENCE-NUMBER ] - -Where the SECRET data is fed to the hash function first, followed by the -ACTUAL-DATA, which is followed by the PADDING-DATA which is -finally followed by the SEQUENCE-NUMBER. The SEQUENCE- -NUMBER is a 32 bit value which is presented to the hash function as four -bytes, with the first byte being the most significant byte of the sequence -number, the second byte being the next most significant byte of the -sequence number, the third byte being the third most significant byte, and -the fourth byte being the least significant byte (that is, in network byte -order or "big endian" order). - -MAC-SIZE is a function of the digest algorithm being used. For MD2 and -MD5 the MAC-SIZE will be 16 bytes (128 bits). - -The SECRET value is a function of which party is sending the message. If -the client is sending the message then the SECRET is the CLIENT- -WRITE-KEY (the server will use the SERVER-READ-KEY to verify -the MAC). If the client is receiving the message then the SECRET is the -CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY -to -generate the MAC). - -Hickman [page 3] - -The SEQUENCE-NUMBER is a counter which is incremented by both -the sender and the receiver. For each transmission direction, a pair of -counters is kept (one by the sender, one by the receiver). Every time a -message is sent by a sender the counter is incremented. Sequence numbers -are 32 bit unsigned quantities and must wrap to zero after incrementing -past 0xFFFFFFFF. - -The receiver of a message uses the expected value of the sequence number -as input into the MAC HASH function (the HASH function is chosen from -the CIPHER-CHOICE). The computed MAC-DATA must agree bit for -bit with the transmitted MAC-DATA. If the comparison is not identity -then the record is considered damaged, and it is to be treated as if an "I/O -Error" had occurred (i.e. an unrecoverable error is asserted and the -connection is closed). - -A final consistency check is done when a block cipher is used and the -protocol is using encryption. The amount of data present in a record -(RECORD-LENGTH))must be a multiple of the cipher's block size. If -the received record is not a multiple of the cipher's block size then the -record is considered damaged, and it is to be treated as if an "I/O Error" -had occurred (i.e. an unrecoverable error is asserted and the connection is -closed). - -The SSL Record Layer is used for all SSL communications, including -handshake messages, security escapes and application data transfers. The -SSL Record Layer is used by both the client and the server at all times. - -For a two byte header, the maximum record length is 32767 bytes. For the -three byte header, the maximum record length is 16383 bytes. The SSL -Handshake Protocol messages are constrained to fit in a single SSL Record -Protocol record. Application protocol messages are allowed to consume -multiple SSL Record Protocol record's. - -Before the first record is sent using SSL all sequence numbers are -initialized to zero. The transmit sequence number is incremented after -every message sent, starting with the CLIENT-HELLO and SERVER- -HELLO messages. - -5. SSL Handshake Protocol Specification - -5.1 SSL Handshake Protocol Flow - -The SSL Handshake Protocol is used to negotiate security enhancements -to data sent using the SSL Record Protocol. The security enhancements -consist of authentication, symmetric encryption, and message integrity. - -The SSL Handshake Protocol has two major phases. The first phase is -used to establish private communications. The second phase is used for -client authentication. - -5.1.1 Phase 1 - -The first phase is the initial connection phase where both parties -communicate their "hello" messages. The client initiates the conversation -by sending the CLIENT-HELLO message. The server receives the - -Hickman [page 4] - -CLIENT-HELLO message and processes it responding with the -SERVER-HELLO message. - -At this point both the client and server have enough information to know -whether or not a new "master key" is needed (The master key is used for -production of the symmetric encryption session keys). When a new master -key is not needed, both the client and the server proceed immediately to -phase 2. - -When a new master key is needed, the SERVER-HELLO message will -contain enough information for the client to generate it. This includes the -server's signed certificate (more about that later), a list of bulk cipher -specifications (see below), and a connection-id (a connection-id is a -randomly generated value generated by the server that is used by the client -and server during a single connection). The client generates the master key -and responds with a CLIENT-MASTER-KEY message (or an ERROR -message if the server information indicates that the client and server -cannot agree on a bulk cipher). - -It should be noted here that each SSL endpoint uses a pair of ciphers per -connection (for a total of four ciphers). At each endpoint, one cipher is -used for outgoing communications, and one is used for incoming -communications. When the client or server generate a session key, they -actually generate two keys, the SERVER-READ-KEY (also known as the -CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known -as the CLIENT-READ-KEY). The master key is used by the client and -server to generate the various session keys (more about that later). - -Finally, the server sends a SERVER-VERIFY message to the client after -the master key has been determined. This final step authenticates the -server, because only a server which has the appropriate public key can -know the master key. - -5.1.2 Phase 2 - -The second phase is the client authentication phase. The server has already -been authenticated by the client in the first phase, so this phase is primarily -used to authenticate the client. In a typical scenario, the server will require -authentication of the client and send a REQUEST-CERTIFICATE -message. The client will answer in the positive if it has the needed -information, or send an ERROR message if it does not. This protocol -specification does not define the semantics of an ERROR response to a -server request (e.g., an implementation can ignore the error, close the -connection, etc. and still conform to this specification). In addition, it is -permissable for a server to cache client authentication information with the -"session-id" cache. The server is not required to re-authenticate the client -on every connection. - -When a party is done authenticating the other party, it sends its finished -message. For the client, the CLIENT-FINISHED message contains the -encrypted form of the CONNECTION-ID for the server to verify. If the -verification fails, the server sends an ERROR message. - -Once a party has sent its finished message it must continue to listen to its -peers messages until it too receives a finished message. Once a party has - -Hickman [page 5] - -both sent a finished message and received its peers finished message, the -SSL handshake protocol is done. At this point the application protocol -begins to operate (Note: the application protocol continues to be layered -on the SSL Record Protocol). - -5.2 Typical Protocol Message Flow - -The following sequences define several typical protocol message flows for -the SSL Handshake Protocol. In these examples we have two principals in -the conversation: the client and the server. We use a notation commonly -found in the literature [10]. When something is enclosed in curly braces -"{something}key" then the something has been encrypted using "key". - -5.2.1 Assuming no session-identifier - -client-hello C -> S: challenge, cipher_specs -server-hello S -> C: connection-id, server_certificate, - cipher_specs -client-master-key C -> S: {master_key}server_public_key -client-finish C -> S: {connection-id}client_write_key -server-verify S -> C: {challenge}server_write_key -server-finish S -> C: {new_session_id}server_write_key - -5.2.2 Assuming a session-identifier was found by both client & server - -client-hello C -> S: challenge, session_id, cipher_specs -server-hello S -> C: connection-id, session_id_hit -client-finish C -> S: {connection-id}client_write_key -server-verify S -> C: {challenge}server_write_key -server-finish S -> C: {session_id}server_write_key - -5.2.3 Assuming a session-identifier was used and client authentication -is used - -client-hello C -> S: challenge, session_id, cipher_specs -server-hello S -> C: connection-id, session_id_hit -client-finish C -> S: {connection-id}client_write_key -server-verify S -> C: {challenge}server_write_key -request-certificate S -> C: {auth_type,challenge'} - server_write_key -client-certificate C -> S: {cert_type,client_cert, - response_data}client_write_key -server-finish S -> C: {session_id}server_write_key - -In this last exchange, the response_data is a function of the auth_type. - -5.3 Errors - -Error handling in the SSL connection protocol is very simple. When an -error is detected, the detecting party sends a message to the other party. -Errors that are not recoverable cause the client and server to abort the -secure connection. Servers and client are required to "forget" any session- -identifiers associated with a failing connection. - -The SSL Handshake Protocol defines the following errors: - - -Hickman [page 6] - -NO-CIPHER-ERROR -This error is returned by the client to the server when it cannot find -a cipher or key size that it supports that is also supported by the -server. This error is not recoverable. - -NO-CERTIFICATE-ERROR -When a REQUEST-CERTIFICATE message is sent, this error may -be returned if the client has no certificate to reply with. This error -is recoverable (for client authentication only). - -BAD-CERTIFICATE-ERROR -This error is returned when a certificate is deemed bad by the -receiving party. Bad means that either the signature of the -certificate was bad or that the values in the certificate were -inappropriate (e.g. a name in the certificate did not match the -expected name). This error is recoverable (for client authentication -only). - -UNSUPPORTED-CERTIFICATE-TYPE-ERROR -This error is returned when a client/server receives a certificate -type that it can't support. This error is recoverable (for client -authentication only). - -5.4 SSL Handshake Protocol Messages - -The SSL Handshake Protocol messages are encapsulated using the SSL -Record Protocol and are composed of two parts: a single byte message -type code, and some data. The client and server exchange messages until -both ends have sent their "finished" message, indicating that they are -satisfied with the SSL Handshake Protocol conversation. While one end -may be finished, the other may not, therefore the finished end must -continue to receive SSL Handshake Protocol messages until it receives a -"finished" message from its peer. - -After the pair of session keys has been determined by each party, the -message bodies are encrypted. For the client, this happens after it verifies -the session-identifier or creates a new master key and has sent it to the -server. For the server, this happens after the session-identifier is found to -be good, or the server receives the client's master key message. - -The following notation is used for SSLHP messages: - -char MSG-EXAMPLE -char FIELD1 -char FIELD2 -char THING-MSB -char THING-LSB -char THING-DATA[(MSB<<8)|LSB]; -... - -This notation defines the data in the protocol message, including the -message type code. The order is presented top to bottom, with the top most -element being transmitted first, and the bottom most element transferred -last. - - -Hickman [page 7] - -For the "THING-DATA" entry, the MSB and LSB values are actually -THING-MSB and THING-LSB (respectively) and define the number of -bytes of data actually present in the message. For example, if THING- -MSB were zero and THING-LSB were 8 then the THING-DATA array -would be exactly 8 bytes long. This shorthand is used below. - -Length codes are unsigned values, and when the MSB and LSB are -combined the result is an unsigned value. Unless otherwise specified -lengths values are "length in bytes". - -5.5 Client Only Protocol Messages - -There are several messages that are only generated by clients. These -messages are never generated by correctly functioning servers. A client -receiving such a message closes the connection to the server and returns an -error status to the application through some unspecified mechanism. - -5.5.1 CLIENT-HELLO (Phase 1; Sent in the clear) - -char MSG-CLIENT-HELLO -char CLIENT-VERSION-MSB -char CLIENT-VERSION-LSB -char CIPHER-SPECS-LENGTH-MSB -char CIPHER-SPECS-LENGTH-LSB -char SESSION-ID-LENGTH-MSB -char SESSION-ID-LENGTH-LSB -char CHALLENGE-LENGTH-MSB -char CHALLENGE-LENGTH-LSB -char CIPHER-SPECS-DATA[(MSB<<8)|LSB] -char SESSION-ID-DATA[(MSB<<8)|LSB] -char CHALLENGE-DATA[(MSB<<8)|LSB] - -When a client first connects to a server it is required to send the CLIENT- -HELLO message. The server is expecting this message from the client as -its first message. It is an error for a client to send anything else as its -first -message. - -The client sends to the server its SSL version, its cipher specs (see below), -some challenge data, and the session-identifier data. The session-identifier -data is only sent if the client found a session-identifier in its cache for the -server, and the SESSION-ID-LENGTH will be non-zero. When there is -no session-identifier for the server SESSION-ID-LENGTH must be zero. -The challenge data is used to authenticate the server. After the client and -server agree on a pair of session keys, the server returns a SERVER- -VERIFY message with the encrypted form of the CHALLENGE-DATA. - -Also note that the server will not send its SERVER-HELLO message -until it has received the CLIENT-HELLO message. This is done so that -the server can indicate the status of the client's session-identifier back to -the client in the server's first message (i.e. to increase protocol efficiency -and reduce the number of round trips required). - -The server examines the CLIENT-HELLO message and will verify that it -can support the client version and one of the client cipher specs. The -server can optionally edit the cipher specs, removing any entries it doesn't - -Hickman [page 8] - -choose to support. The edited version will be returned in the SERVER- -HELLO message if the session-identifier is not in the server's cache. - -The CIPHER-SPECS-LENGTH must be greater than zero and a -multiple of 3. The SESSION-ID-LENGTH must either be zero or 16. -The CHALLENGE-LENGTH must be greater than or equal to 16 and -less than or equal to 32. - -This message must be the first message sent by the client to the server. -After the message is sent the client waits for a SERVER-HELLO -message. Any other message returned by the server (other than ERROR) -is disallowed. - -5.5.2 CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear) - -char MSG-CLIENT-MASTER-KEY -char CIPHER-KIND[3] -char CLEAR-KEY-LENGTH-MSB -char CLEAR-KEY-LENGTH-LSB -char ENCRYPTED-KEY-LENGTH-MSB -char ENCRYPTED-KEY-LENGTH-LSB -char KEY-ARG-LENGTH-MSB -char KEY-ARG-LENGTH-LSB -char CLEAR-KEY-DATA[MSB<<8|LSB] -char ENCRYPTED-KEY-DATA[MSB<<8|LSB] -char KEY-ARG-DATA[MSB<<8|LSB] - -The client sends this message when it has determined a master key for the -server to use. Note that when a session-identifier has been agreed upon, -this message is not sent. - -The CIPHER-KIND field indicates which cipher was chosen from the -server's CIPHER-SPECS. - -The CLEAR-KEY-DATA contains the clear portion of the MASTER- -KEY. The CLEAR-KEY-DATA is combined with the SECRET-KEY- -DATA (described shortly) to form the MASTER-KEY, with the -SECRET-KEY-DATA being the least significant bytes of the final -MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret -portions of the MASTER-KEY, encrypted using the server's public key. -The encryption block is formatted using block type 2 from PKCS#1 [5]. -The data portion of the block is formatted as follows: - -char SECRET-KEY-DATA[SECRET-LENGTH] - -SECRET-LENGTH is the number of bytes of each session key that is -being transmitted encrypted. The SECRET-LENGTH plus the CLEAR- -KEY-LENGTH equals the number of bytes present in the cipher key (as -defined by the CIPHER-KIND). It is an error if the SECRET-LENGTH -found after decrypting the PKCS#1 formatted encryption block doesn't -match the expected value. It is also an error if CLEAR-KEY-LENGTH is -non-zero and the CIPHER-KIND is not an export cipher. - -If the key algorithm needs an argument (for example, DES-CBC's -initialization vector) then the KEY-ARG-LENGTH fields will be non- - -Hickman [page 9] - -zero and the KEY-ARG-DATA will contain the relevant data. For the -SSL_CK_RC2_128_CBC_WITH_MD5, -SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, -SSL_CK_IDEA_128_CBC_WITH_MD5, -SSL_CK_DES_64_CBC_WITH_MD5 and -SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG -data must be present and be exactly 8 bytes long. - -Client and server session key production is a function of the CIPHER- -CHOICE: - -SSL_CK_RC4_128_WITH_MD5 -SSL_CK_RC4_128_EXPORT40_WITH_MD5 -SSL_CK_RC2_128_CBC_WITH_MD5 -SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 -SSL_CK_IDEA_128_CBC_WITH_MD5 - -KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, -CONNECTION-ID ] -KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, -CONNECTION-ID ] - -CLIENT-READ-KEY = KEY-MATERIAL-0[0-15] -CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15] - -Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the KEY- -MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the most -significant byte of the CLIENT-READ-KEY. - -Data is fed to the MD5 hash function in the order shown, from left to -right: first the MASTER-KEY, then the "0" or "1", then the -CHALLENGE and then finally the CONNECTION-ID. - -Note that the "0" means the ascii zero character (0x30), not a zero value. -"1" means the ascii 1 character (0x31). MD5 produces 128 bits of output -data which are used directly as the key to the cipher algorithm (The most -significant byte of the MD5 output becomes the most significant byte of -the key material). - -SSL_CK_DES_64_CBC_WITH_MD5 - - KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, -CONNECTION-ID ] - - CLIENT-READ-KEY = KEY-MATERIAL-0[0-7] - CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15] - -For DES-CBC, a single 16 bytes of key material are produced using MD5. -The first 8 bytes of the MD5 digest are used as the CLIENT-READ-KEY -while the remaining 8 bytes are used as the CLIENT-WRITE-KEY. The -initialization vector is provided in the KEY-ARG-DATA. Note that the -raw key data is not parity adjusted and that this step must be performed -before the keys are legitimate DES keys. - -SSL_CK_DES_192_EDE3_CBC_WITH_MD5 - - -Hickman [page 10] - - KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, -CONNECTION-ID ] - KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, -CONNECTION-ID ] - KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, -CONNECTION-ID ] - - CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7] - CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15] - CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7] - CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15] - CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7] - CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15] - -Data is fed to the MD5 hash function in the order shown, from left to -right: first the MASTER-KEY, then the "0", "1" or "2", then the -CHALLENGE and then finally the CONNECTION-ID. Note that the -"0" means the ascii zero character (0x30), not a zero value. "1" means the -ascii 1 character (0x31). "2" means the ascii 2 character (0x32). - -A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher and 3 -for the write side DES-EDE3 function. The initialization vector is -provided in the KEY-ARG-DATA. The keys that are produced are not -parity adjusted. This step must be performed before proper DES keys are -usable. - -Recall that the MASTER-KEY is given to the server in the CLIENT- -MASTER-KEY message. The CHALLENGE is given to the server by -the client in the CLIENT-HELLO message. The CONNECTION-ID is -given to the client by the server in the SERVER-HELLO message. This -makes the resulting cipher keys a function of the original session and the -current session. Note that the master key is never directly used to encrypt -data, and therefore cannot be easily discovered. - -The CLIENT-MASTER-KEY message must be sent after the CLIENT- -HELLO message and before the CLIENT-FINISHED message. The -CLIENT-MASTER-KEY message must be sent if the SERVER- -HELLO message contains a SESSION-ID-HIT value of 0. - -5.5.3 CLIENT-CERTIFICATE (Phase 2; Sent encrypted) - -char MSG-CLIENT-CERTIFICATE -char CERTIFICATE-TYPE -char CERTIFICATE-LENGTH-MSB -char CERTIFICATE-LENGTH-LSB -char RESPONSE-LENGTH-MSB -char RESPONSE-LENGTH-LSB -char CERTIFICATE-DATA[MSB<<8|LSB] -char RESPONSE-DATA[MSB<<8|LSB] - -This message is sent by one an SSL client in response to a server -REQUEST-CERTIFICATE message. The CERTIFICATE-DATA -contains data defined by the CERTIFICATE-TYPE value. An ERROR -message is sent with error code NO-CERTIFICATE-ERROR when this -request cannot be answered properly (e.g. the receiver of the message has - -Hickman [page 11] - -no registered certificate). - -CERTIFICATE-TYPE is one of: - -SSL_X509_CERTIFICATE -The CERTIFICATE-DATA contains an X.509 (1988) [3] signed -certificate. - -The RESPONSE-DATA contains the authentication response data. This -data is a function of the AUTHENTICATION-TYPE value sent by the -server. - -When AUTHENTICATION-TYPE is -SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE- -DATA contains a digital signature of the following components (in the -order shown): - - the KEY-MATERIAL-0 - the KEY-MATERIAL-1 (only if defined by the cipher kind) - the KEY-MATERIAL-2 (only if defined by the cipher kind) - the CERTIFICATE-CHALLENGE-DATA (from the -REQUEST-CERTIFICATE message) - the server's signed certificate (from the SERVER-HELLO -message) - -The digital signature is constructed using MD5 and then encrypted using -the clients private key, formatted according to PKCS#1's digital signature -standard [5]. The server authenticates the client by verifying the digital -signature using standard techniques. Note that other digest functions are -supported. Either a new AUTHENTICATION-TYPE can be added, or -the algorithm-id in the digital signature can be changed. - -This message must be sent by the client only in response to a REQUEST- -CERTIFICATE message. - -5.5.4 CLIENT-FINISHED (Phase 2; Sent encrypted) - -char MSG-CLIENT-FINISHED -char CONNECTION-ID[N-1] - -The client sends this message when it is satisfied with the server. Note that -the client must continue to listen for server messages until it receives a -SERVER-FINISHED message. The CONNECTION-ID data is the -original connection-identifier the server sent with its SERVER-HELLO -message, encrypted using the agreed upon session key. - -"N" is the number of bytes in the message that was sent, so "N-1" is the -number of bytes in the message without the message header byte. - -For version 2 of the protocol, the client must send this message after it has -received the SERVER-HELLO message. If the SERVER-HELLO -message SESSION-ID-HIT flag is non-zero then the CLIENT- -FINISHED message is sent immediately, otherwise the CLIENT- -FINISHED message is sent after the CLIENT-MASTER-KEY message. - - -Hickman [page 12] - - - - - - -5.6 Server Only Protocol Messages - -There are several messages that are only generated by servers. The -messages are never generated by correctly functioning clients. - -5.6.1 SERVER-HELLO (Phase 1; Sent in the clear) - -char MSG-SERVER-HELLO -char SESSION-ID-HIT -char CERTIFICATE-TYPE -char SERVER-VERSION-MSB -char SERVER-VERSION-LSB -char CERTIFICATE-LENGTH-MSB -char CERTIFICATE-LENGTH-LSB -char CIPHER-SPECS-LENGTH-MSB -char CIPHER-SPECS-LENGTH-LSB -char CONNECTION-ID-LENGTH-MSB -char CONNECTION-ID-LENGTH-LSB -char CERTIFICATE-DATA[MSB<<8|LSB] -char CIPHER-SPECS-DATA[MSB<<8|LSB] -char CONNECTION-ID-DATA[MSB<<8|LSB] - -The server sends this message after receiving the clients CLIENT- -HELLO message. The server returns the SESSION-ID-HIT flag -indicating whether or not the received session-identifier is known by the -server (i.e. in the server's session-identifier cache). The SESSION-ID- -HIT flag will be non-zero if the client sent the server a session-identifier -(in the CLIENT-HELLO message with SESSION-ID-LENGTH != 0) -and the server found the client's session-identifier in its cache. If the -SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, -CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will -be zero. - -The CERTIFICATE-TYPE value, when non-zero, has one of the values -described above (see the information on the CLIENT-CERTIFICATE -message). - -When the SESSION-ID-HIT flag is zero, the server packages up its -certificate, its cipher specs and a connection-id to send to the client. Using -this information the client can generate a session key and return it to the -server with the CLIENT-MASTER-KEY message. - -When the SESSION-ID-HIT flag is non-zero, both the server and the -client compute a new pair of session keys for the current session derived -from the MASTER-KEY that was exchanged when the SESSION-ID -was created. The SERVER-READ-KEY and SERVER-WRITE-KEY -are derived from the original MASTER-KEY keys in the same manner as -the CLIENT-READ-KEY and CLIENT-WRITE-KEY: - -SERVER-READ-KEY = CLIENT-WRITE-KEY -SERVER-WRITE-KEY = CLIENT-READ-KEY - -Note that when keys are being derived and the SESSION-ID-HIT flag is -set and the server discovers the client's session-identifier in the servers -cache, then the KEY-ARG-DATA is used from the time when the - -Hickman [page 13] - -SESSION-ID was established. This is because the client does not send -new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in -the CLIENT-MASTER-KEY message). - -The CONNECTION-ID-DATA is a string of randomly generated bytes -used by the server and client at various points in the protocol. The -CLIENT-FINISHED message contains an encrypted version of the -CONNECTION-ID-DATA. The length of the CONNECTION-ID must -be between 16 and than 32 bytes, inclusive. - -The CIPHER-SPECS-DATA define a cipher type and key length (in bits) -that the receiving end supports. Each SESSION-CIPHER-SPEC is 3 -bytes long and looks like this: - -char CIPHER-KIND-0 -char CIPHER-KIND-1 -char CIPHER-KIND-2 - -Where CIPHER-KIND is one of: - -SSL_CK_RC4_128_WITH_MD5 -SSL_CK_RC4_128_EXPORT40_WITH_MD5 -SSL_CK_RC2_128_CBC_WITH_MD5 -SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 -SSL_CK_IDEA_128_CBC_WITH_MD5 -SSL_CK_DES_64_CBC_WITH_MD5 -SSL_CK_DES_192_EDE3_CBC_WITH_MD5 - -This list is not exhaustive and may be changed in the future. - -The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4 -cipher where some of the session key is sent in the clear and the rest is sent -encrypted (exactly 40 bits of it). MD5 is used as the hash function for -production of MAC's and session key's. This cipher type is provided to -support "export" versions (i.e. versions of the protocol that can be -distributed outside of the United States) of the client or server. - -An exportable implementation of the SSL Handshake Protocol will have -secret key lengths restricted to 40 bits. For non-export implementations -key lengths can be more generous (we recommend at least 128 bits). It is -permissible for the client and server to have a non-intersecting set of -stream ciphers. This, simply put, means they cannot communicate. - -Version 2 of the SSL Handshake Protocol defines the -SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The -SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of -128 bits. However, only 40 of the bits are secret (the other 88 bits are sent -in the clear by the client to the server). - -The SERVER-HELLO message is sent after the server receives the -CLIENT-HELLO message, and before the server sends the SERVER- -VERIFY message. -5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted) - -char MSG-SERVER-VERIFY - -Hickman [page 14] - -char CHALLENGE-DATA[N-1] - -The server sends this message after a pair of session keys (SERVER- -READ-KEY and SERVER-WRITE-KEY) have been agreed upon either -by a session-identifier or by explicit specification with the CLIENT- -MASTER-KEY message. The message contains an encrypted copy of the -CHALLENGE-DATA sent by the client in the CLIENT-HELLO -message. - -"N" is the number of bytes in the message that was sent, so "N-1" is the -number of bytes in the CHALLENGE-DATA without the message -header byte. - -This message is used to verify the server as follows. A legitimate server -will have the private key that corresponds to the public key contained in -the server certificate that was transmitted in the SERVER-HELLO -message. Accordingly, the legitimate server will be able to extract and -reconstruct the pair of session keys (SERVER-READ-KEY and -SERVER-WRITE-KEY). Finally, only a server that has done the -extraction and decryption properly can correctly encrypt the -CHALLENGE-DATA. This, in essence, "proves" that the server has the -private key that goes with the public key in the server's certificate. - -The CHALLENGE-DATA must be the exact same length as originally -sent by the client in the CLIENT-HELLO message. Its value must match -exactly the value sent in the clear by the client in the CLIENT-HELLO -message. The client must decrypt this message and compare the value -received with the value sent, and only if the values are identical is the -server to be "trusted". If the lengths do not match or the value doesn't -match then the connection is to be closed by the client. - -This message must be sent by the server to the client after either detecting -a session-identifier hit (and replying with a SERVER-HELLO message -with SESSION-ID-HIT not equal to zero) or when the server receives the -CLIENT-MASTER-KEY message. This message must be sent before -any Phase 2 messages or a SERVER-FINISHED message. - -5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted) - -char MSG-SERVER-FINISHED -char SESSION-ID-DATA[N-1] - -The server sends this message when it is satisfied with the clients security -handshake and is ready to proceed with transmission/reception of the -higher level protocols data. The SESSION-ID-DATA is used by the client -and the server at this time to add entries to their respective session- -identifier caches. The session-identifier caches must contain a copy of the -MASTER-KEY sent in the CLIENT-MASTER-KEY message as the -master key is used for all subsequent session key generation. - -"N" is the number of bytes in the message that was sent, so "N-1" is the -number of bytes in the SESSION-ID-DATA without the message header -byte. - -This message must be sent after the SERVER-VERIFY message. - -Hickman [page 15] - -5.6.4 REQUEST-CERTIFICATE (Phase 2; Sent encrypted) - -char MSG-REQUEST-CERTIFICATE -char AUTHENTICATION-TYPE -char CERTIFICATE-CHALLENGE-DATA[N-2] - -A server may issue this request at any time during the second phase of the -connection handshake, asking for the client's certificate. The client -responds with a CLIENT-CERTIFICATE message immediately if it has -one, or an ERROR message (with error code NO-CERTIFICATE- -ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is a -short byte string (whose length is greater than or equal to 16 bytes and less -than or equal to 32 bytes) that the client will use to respond to this -message. - -The AUTHENTICATION-TYPE value is used to choose a particular -means of authenticating the client. The following types are defined: - -SSL_AT_MD5_WITH_RSA_ENCRYPTION - -The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the -client construct an MD5 message digest using information as described -above in the section on the CLIENT-CERTIFICATE message. Once the -digest is created, the client encrypts it using its private key (formatted -according to the digital signature standard defined in PKCS#1). The server -authenticates the client when it receives the CLIENT-CERTIFICATE -message. - -This message may be sent after a SERVER-VERIFY message and before -a SERVER-FINISHED message. - -5.7 Client/Server Protocol Messages - -These messages are generated by both the client and the server. - -5.7.1 ERROR (Sent clear or encrypted) - -char MSG-ERROR -char ERROR-CODE-MSB -char ERROR-CODE-LSB - -This message is sent when an error is detected. After the message is sent, -the sending party shuts the connection down. The receiving party records -the error and then shuts its connection down. - -This message is sent in the clear if an error occurs during session key -negotiation. After a session key has been agreed upon, errors are sent -encrypted like all other messages. - -Appendix A: ASN.1 Syntax For Certificates - -Certificates are used by SSL to authenticate servers and clients. SSL -Certificates are based largely on the X.509 [3] certificates. An X.509 -certificate contains the following information (in ASN.1 [1] notation): - -Hickman [page 16] - -X.509-Certificate ::= SEQUENCE { - certificateInfo CertificateInfo, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING -} - -CertificateInfo ::= SEQUENCE { - version [0] Version DEFAULT v1988, - serialNumber CertificateSerialNumber, - signature AlgorithmIdentifier, - issuer Name, - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo -} - -Version ::= INTEGER { v1988(0) } - -CertificateSerialNumber ::= INTEGER - -Validity ::= SEQUENCE { - notBefore UTCTime, - notAfter UTCTime -} - -SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING -} - -AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY ALGORITHM OPTIONAL -} - -For SSL's purposes we restrict the values of some of the X.509 fields: - - The X.509-Certificate::signatureAlgorithm and -CertificateInfo::signature fields must be identical in value. - - The issuer name must resolve to a name that is deemed acceptable by -the application using SSL. How the application using SSL does this is -outside the scope of this memo. - -Certificates are validated using a few straightforward steps. First, the -signature on the certificate is checked and if invalid, the certificate is -invalid (either a transmission error or an attempted forgery occurred). -Next, the CertificateInfo::issuer field is verified to be an issuer that the -application trusts (using an unspecified mechanism). The -CertificateInfo::validity field is checked against the current date and -verified. - -Finally, the CertificateInfo::subject field is checked. This check is -optional and depends on the level of trust required by the application using -SSL. - -Hickman [page 17] - -Appendix B: Attribute Types and Object Identifiers - -SSL uses a subset of the X.520 selected attribute types as well as a -few specific object identifiers. Future revisions of the SSL protocol -may include support for more attribute types and more object -identifiers. - -B.1 Selected attribute types - -commonName { attributeType 3 } -The common name contained in the distinguished name contained -within a certificate issuer or certificate subject. - -countryName { attributeType 6 } -The country name contained in the distinguished name contained -within a certificate issuer or certificate subject. - -localityName { attributeType 7 } -The locality name contained in the distinguished name contained -within a certificate issuer or certificate subject. - -stateOrProvinceName { attributeType 8 } -The state or province name contained in the distinguished name -contained within a certificate issuer or certificate subject. - -organizationName { attributeType 10 } -The organization name contained in the distinguished name contained -within a certificate issuer or certificate subject. - -organizationalUnitName { attributeType 11 } -The organizational unit name contained in the distinguished name -contained within a certificate issuer or certificate subject. - -B.2 Object identifiers - -md2withRSAEncryption { ... pkcs(1) 1 2 } -The object identifier for digital signatures that use both MD2 and RSA -encryption. Used by SSL for certificate signature verification. - -md5withRSAEncryption { ... pkcs(1) 1 4 } -The object identifier for digital signatures that use both MD5 and RSA -encryption. Used by SSL for certificate signature verification. - -rc4 { ... rsadsi(113549) 3 4 } -The RC4 symmetric stream cipher algorithm used by SSL for bulk -encryption. - -Appendix C: Protocol Constant Values - -This section describes various protocol constants. A special value needs -mentioning - the IANA reserved port number for "https" (HTTP using -SSL). IANA has reserved port number 443 (decimal) for "https". IANA -has also reserved port number 465 for "ssmtp" and port number 563 for -"snntp". - -Hickman [page 18] - -C.1 Protocol Version Codes - -#define SSL_CLIENT_VERSION 0x0002 -#define SSL_SERVER_VERSION 0x0002 - -C.2 Protocol Message Codes - -The following values define the message codes that are used by version -2 of the SSL Handshake Protocol. - -#define SSL_MT_ERROR 0 -#define SSL_MT_CLIENT_HELLO 1 -#define SSL_MT_CLIENT_MASTER_KEY 2 -#define SSL_MT_CLIENT_FINISHED 3 -#define SSL_MT_SERVER_HELLO 4 -#define SSL_MT_SERVER_VERIFY 5 -#define SSL_MT_SERVER_FINISHED 6 -#define SSL_MT_REQUEST_CERTIFICATE 7 -#define SSL_MT_CLIENT_CERTIFICATE 8 - -C.3 Error Message Codes - -The following values define the error codes used by the ERROR message. - -#define SSL_PE_NO_CIPHER 0x0001 -#define SSL_PE_NO_CERTIFICATE 0x0002 -#define SSL_PE_BAD_CERTIFICATE 0x0004 -#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006 - -C.4 Cipher Kind Values - -The following values define the CIPHER-KIND codes used in the -CLIENT-HELLO and SERVER-HELLO messages. - -#define SSL_CK_RC4_128_WITH_MD5 - 0x01,0x00,0x80 -#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 - 0x02,0x00,0x80 -#define SSL_CK_RC2_128_CBC_WITH_MD5 - 0x03,0x00,0x80 -#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 - 0x04,0x00,0x80 -#define SSL_CK_IDEA_128_CBC_WITH_MD5 - 0x05,0x00,0x80 -#define SSL_CK_DES_64_CBC_WITH_MD5 - 0x06,0x00,0x40 -#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 - 0x07,0x00,0xC0 - -C.5 Certificate Type Codes - -The following values define the certificate type codes used in the -SERVER-HELLO and CLIENT-CERTIFICATE messages. - -#define SSL_CT_X509_CERTIFICATE 0x01 - -Hickman [page 19] - -C.6 Authentication Type Codes - -The following values define the authentication type codes used in the -REQUEST-CERTIFICATE message. - -#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01 - -C.7 Upper/Lower Bounds - -The following values define upper/lower bounds for various protocol -parameters. - -#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256 -#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16 -#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64 -#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767 -#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383 - -C.8 Recommendations - -Because protocols have to be implemented to be of value, we recommend -the following values for various operational parameters. This is only a -recommendation, and not a strict requirement for conformance to the -protocol. - -Session-identifier Cache Timeout - -Session-identifiers are kept in SSL clients and SSL servers. Session- -identifiers should have a lifetime that serves their purpose (namely, -reducing the number of expensive public key operations for a single -client/server pairing). Consequently, we recommend a maximum session- -identifier cache timeout value of 100 seconds. Given a server that can -perform N private key operations per second, this reduces the server load -for a particular client by a factor of 100. - -Appendix D: Attacks - -In this section we attempt to describe various attacks that might be used -against the SSL protocol. This list is not guaranteed to be exhaustive. SSL -was defined to thwart these attacks. - -D.1 Cracking Ciphers - -SSL depends on several cryptographic technologies. RSA Public Key -encryption [5] is used for the exchange of the session key and client/server -authentication. Various cryptographic algorithms are used for the session -cipher. If successful cryptographic attacks are made against these -technologies then SSL is no longer secure. - -Attacks against a specific communications session can be made by -recording the session, and then spending some large number of compute -cycles to crack either the session key or the RSA public key until the -communication can be seen in the clear. This approach is easier than -cracking the cryptographic technologies for all possible messages. Note -that SSL tries to make the cost of such of an attack greater than the - -Hickman [page 20] - -benefits gained from a successful attack, thus making it a waste of -money/time to perform such an attack. - -There have been many books [9] and papers [10] written on cryptography. -This document does not attempt to reference them all. - -D.2 Clear Text Attack - -A clear text attack is done when the attacker has an idea of what kind of -message is being sent using encryption. The attacker can generate a data -base whose keys are the encrypted value of the known text (or clear text), -and whose values are the session cipher key (we call this a "dictionary"). -Once this data base is constructed, a simple lookup function identifies the -session key that goes with a particular encrypted value. Once the session -key is known, the entire message stream can be decrypted. Custom -hardware can be used to make this cost effective and very fast. - -Because of the very nature of SSL clear text attacks are possible. For -example, the most common byte string sent by an HTTP client application -to an HTTP server is "GET". SSL attempts to address this attack by using -large session cipher keys. First, the client generates a key which is larger -than allowed by export, and sends some of it in the clear to the server (this -is allowed by United States government export rules). The clear portion of -the key concatenated with the secret portion make a key which is very -large (for RC4, exactly 128 bits). - -The way that this "defeats" a clear text attack is by making the amount of -custom hardware needed prohibitively large. Every bit added to the length -of the session cipher key increases the dictionary size by a factor of 2. By -using a 128 bit session cipher key length the size of the dictionary required -is beyond the ability of anyone to fabricate (it would require more atoms to -construct than exist in the entire universe). Even if a smaller dictionary is -to be used, it must first be generated using the clear key bits. This is a time -consumptive process and also eliminates many possible custom hardware -architectures (e.g. static prom arrays). - -The second way that SSL attacks this problem is by using large key -lengths when permissible (e.g. in the non-export version). Large key sizes -require larger dictionaries (just one more bit of key size doubles the size of -the dictionary). SSL attempts to use keys that are 128 bits in length. - -Note that the consequence of the SSL defense is that a brute force attack -becomes the cheapest way to attack the key. Brute force attacks have well -known space/time tradeoffs and so it becomes possible to define a cost of -the attack. For the 128 bit secret key, the known cost is essentially infinite. -For the 40 bit secret key, the cost is much smaller, but still outside the -range of the "random hacker". - -D.3 Replay - -The replay attack is simple. A bad-guy records a communication session -between a client and server. Later, it reconnects to the server, and plays -back the previously recorded client messages. SSL defeats this attack -using a "nonce" (the connection-id) which is "unique" to the connection. In -theory the bad-guy cannot predict the nonce in advance as it is based on a - -Hickman [page 21] - -set of random events outside the bad-guys control, and therefore the bad- -guy cannot respond properly to server requests. - -A bad-guy with large resources can record many sessions between a client -and a server, and attempt to choose the right session based on the nonce -the server sends initially in its SERVER-HELLO message. However, SSL -nonces are at least 128 bits long, so a bad-guy would need to record -approximately 2^64 nonces to even have a 50% chance of choosing the -right session. This number is sufficiently large that one cannot -economically construct a device to record 2^64 messages, and therefore -the odds are overwhelmingly against the replay attack ever being -successful. - -D.4 The Man In The Middle - -The man in the middle attack works by having three people in a -communications session: the client, the server, and the bad guy. The bad -guy sits between the client and the server on the network and intercepts -traffic that the client sends to the server, and traffic that the server -sends to -the client. - -The man in the middle operates by pretending to be the real server to the -client. With SSL this attack is impossible because of the usage of server -certificates. During the security connection handshake the server is -required to provide a certificate that is signed by a certificate authority. -Contained in the certificate is the server's public key as well as its name -and the name of the certificate issuer. The client verifies the certificate by -first checking the signature and then verifying that the name of the issuer -is somebody that the client trusts. - -In addition, the server must encrypt something with the private key that -goes with the public key mentioned in the certificate. This in essence is a -single pass "challenge response" mechanism. Only a server that has both -the certificate and the private key can respond properly to the challenge. - -If the man in the middle provides a phony certificate, then the signature -check will fail. If the certificate provided by the bad guy is legitimate, but -for the bad guy instead of for the real server, then the signature will pass -but the name check will fail (note that the man in the middle cannot forge -certificates without discovering a certificate authority's private key). - -Finally, if the bad guy provides the real server's certificate then the -signature check will pass and the name check will pass. However, because -the bad guy does not have the real server's private key, the bad guy cannot -properly encode the response to the challenge code, and this check will -fail. - -In the unlikely case that a bad guy happens to guess the response code to -the challenge, the bad guy still cannot decrypt the session key and -therefore cannot examine the encrypted data. - - -Hickman [page 22] - -Appendix E: Terms - -Application Protocol -An application protocol is a protocol that normally layers directly on -top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP. - -Authentication -Authentication is the ability of one entity to determine the identity of -another entity. Identity is defined by this document to mean the -binding between a public key and a name and the implicit ownership -of the corresponding private key. - -Bulk Cipher -This term is used to describe a cryptographic technique with certain -performance properties. Bulk ciphers are used when large quantities of -data are to be encrypted/decrypted in a timely manner. Examples -include RC2, RC4, and IDEA. - -Client -In this document client refers to the application entity that is initiates a -connection to a server. - -CLIENT-READ-KEY -The session key that the client uses to initialize the client read cipher. -This key has the same value as the SERVER-WRITE-KEY. - -CLIENT-WRITE-KEY -The session key that the client uses to initialize the client write cipher. -This key has the same value as the SERVER-READ-KEY. - -MASTER-KEY -The master key that the client and server use for all session key -generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, -SERVER-READ-KEY and SERVER-WRITE-KEY are generated -from the MASTER-KEY. - -MD2 -MD2 [8] is a hashing function that converts an arbitrarily long data -stream into a digest of fixed size. This function predates MD5 [7] -which is viewed as a more robust hash function [9]. - -MD5 -MD5 [7] is a hashing function that converts an arbitrarily long data -stream into a digest of fixed size. The function has certain properties -that make it useful for security, the most important of which is it's -inability to be reversed. - -Nonce -A randomly generated value used to defeat "playback" attacks. One -party randomly generates a nonce and sends it to the other party. The -receiver encrypts it using the agreed upon secret key and returns it to -the sender. Because the nonce was randomly generated by the sender -this defeats playback attacks because the replayer can't know in -advance the nonce the sender will generate. The receiver denies -connections that do not have the correctly encrypted nonce. - -Hickman [page 23] - -Non-repudiable Information Exchange -When two entities exchange information it is sometimes valuable to -have a record of the communication that is non-repudiable. Neither -party can then deny that the information exchange occurred. Version 2 -of the SSL protocol does not support Non-repudiable information -exchange. - -Public Key Encryption -Public key encryption is a technique that leverages asymmetric ciphers. -A public key system consists of two keys: a public key and a private -key. Messages encrypted with the public key can only be decrypted -with the associated private key. Conversely, messages encrypted with -the private key can only be decrypted with the public key. Public key -encryption tends to be extremely compute intensive and so is not -suitable as a bulk cipher. - -Privacy -Privacy is the ability of two entities to communicate without fear of -eavesdropping. Privacy is often implemented by encrypting the -communications stream between the two entities. - -RC2, RC4 -Proprietary bulk ciphers invented by RSA (There is no good reference -to these as they are unpublished works; however, see [9]). RC2 is -block cipher and RC4 is a stream cipher. - -Server -The server is the application entity that responds to requests for -connections from clients. The server is passive, waiting for requests -from clients. - -Session cipher -A session cipher is a "bulk" cipher that is capable of encrypting or -decrypting arbitrarily large amounts of data. Session ciphers are used -primarily for performance reasons. The session ciphers used by this -protocol are symmetric. Symmetric ciphers have the property of using -a single key for encryption and decryption. - -Session identifier -A session identifier is a random value generated by a client that -identifies itself to a particular server. The session identifier can be -thought of as a handle that both parties use to access a recorded secret -key (in our case a session key). If both parties remember the session -identifier then the implication is that the secret key is already known -and need not be negotiated. - -Session key -The key to the session cipher. In SSL there are four keys that are called -session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, -SERVER-READ-KEY, and SERVER-WRITE-KEY. - -SERVER-READ-KEY -The session key that the server uses to initialize the server read cipher. -This key has the same value as the CLIENT-WRITE-KEY. - - -Hickman [page 24] - -SERVER-WRITE-KEY -The session key that the server uses to initialize the server write cipher. -This key has the same value as the CLIENT-READ-KEY. - -Symmetric Cipher -A symmetric cipher has the property that the same key can be used for -decryption and encryption. An asymmetric cipher does not have this -behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4. - - - -References - -[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax -Notation One (ASN.1). 1988. - -[2] CCITT. Recommendation X.209: "Specification of Basic Encoding -Rules for Abstract Syntax Notation One (ASN.1). 1988. - -[3] CCITT. Recommendation X.509: "The Directory - Authentication -Framework". 1988. - -[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute -Types". 1988. - -[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, -November 1993. - -[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, -Version 1.5, November 1993. - -[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April -1992. - -[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April -1992. - -[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source -Code in C, Published by John Wiley & Sons, Inc. 1994. - -[10] M. Abadi and R. Needham. Prudent engineering practice for -cryptographic protocols. 1994. - -Patent Statement - -This version of the SSL protocol relies on the use of patented public key -encryption technology for authentication and encryption. The Internet -Standards Process as defined in RFC 1310 requires a written statement -from the Patent holder that a license will be made available to applicants -under reasonable terms and conditions prior to approving a specification as -a Proposed, Draft or Internet Standard. - -The Massachusetts Institute of Technology and the Board of Trustees of -the Leland Stanford Junior University have granted Public Key Partners -(PKP) exclusive sub-licensing rights to the following patents issued in the - -Hickman [page 25] - -United States, and all of their corresponding foreign patents: - -Cryptographic Apparatus and Method ("Diffie-Hellman") - No. 4,200,770 - -Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") - No. 4,218,582 - -Cryptographic Communications System and Method ("RSA") - No. 4,405,829 - -Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") - No. 4,424,414 - -These patents are stated by PKP to cover all known methods of practicing -the art of Public Key encryption, including the variations collectively -known as ElGamal. - -Public Key Partners has provided written assurance to the Internet Society -that parties will be able to obtain, under reasonable, nondiscriminatory -terms, the right to use the technology covered by these patents. This -assurance is documented in RFC 1170 titled "Public Key Standards and -Licenses". A copy of the written assurance dated April 20, 1990, may be -obtained from the Internet Assigned Number Authority (IANA). - -The Internet Society, Internet Architecture Board, Internet Engineering -Steering Group and the Corporation for National Research Initiatives take -no position on the validity or scope of the patents and patent applications, -nor on the appropriateness of the terms of the assurance. The Internet -Society and other groups mentioned above have not made any -determination as to any other intellectual property rights which may apply -to the practice of this standard. Any further consideration of these matters -is the user's own responsibility. - -Security Considerations - -This entire document is about security. - -Author's Address - -Kipp E.B. Hickman -Netscape Communications Corp. -501 East Middlefield Rd. -Mountain View, CA 94043 -kipp@netscape.com - - -Hickman [page 26] - - - - - - - |