Kipp E.B. HickmanInternet Draft Netscape Communications Corp April 1995 (Expires 10/95) The SSL Protocol <draft-hickman-netscape-ssl-00.txt>1. STATUS OF THIS MEMOThis document is an Internet-Draft.Internet-Drafts are working documentsof the Internet Engineering Task Force (IETF), its areas, and its workinggroups. Note that other groups may also distribute working documents asInternet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference material or tocite 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 Directorieson ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (USWest Coast), or munnari.oz.au (Pacific Rim).2. ABSTRACTThis document specifies the Secure Sockets Layer (SSL) protocol, asecurity protocol that provides privacy over the Internet. The protocolallows client/server applications to communicate in a way that cannot beeavesdropped. Server's are always authenticated and clients are optionallyauthenticated.3. INTRODUCTIONThe SSL Protocol is designed to provide privacy between twocommunicating applications (a client and a server). Second, the protocol isdesigned to authenticate the server, and optionally the client. SSL requiresa reliable transport protocol (e.g. TCP) for data transmission andreception.The advantage of the SSL Protocol is that it is application protocolindependent. A "higher level" application protocol (e.g. HTTP, FTP,TELNET, etc.) can layer on top of the SSL Protocol transparently. TheSSL Protocol can negotiate an encryption algorithm and session key aswell as authenticate a server before the application protocol transmits orreceives its first byte of data. All of the application protocol data istransmitted encrypted, ensuring privacy.The SSL protocol provides "channel security" which has three basicproperties: The channel is private. Encryption is used for all messages after asimple handshake is used to define a secret key. Symmetriccryptography is used for data encryption (e.g. DES, RC4, etc.) The channel is authenticated. The server endpoint of the conversationis always authenticated, while the client endpoint is optionallyauthenticated. Asymmetric cryptography is used for authenticationHickman [page 1](e.g. Public Key Cryptography). The channel is reliable. The message transport includes a messageintegrity 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 lowestlevel, layered on top of some reliable transport protocol, is the "SSLRecord Protocol". The SSL Record Protocol is used for encapsulation ofall transmitted and received data, including the SSL Handshake Protocol,which is used to establish security parameters.4. SSL Record Protocol Specification4.1 SSL Record Header FormatIn SSL, all data sent is encapsulated in a record, an object which iscomposed of a header and some non-zero amount of data. Each recordheader contains a two or three byte length code. If the most significant bitis set in the first byte of the record length code then the record has nopadding and the total header length will be 2 bytes, otherwise the recordhas padding and the total header length will be 3 bytes. The record headeris transmitted before the data portion of the record.Note that in the long header case (3 bytes total), the second mostsignificant bit in the first byte has special meaning. When zero, the recordbeing sent is a data record. When one, the record being sent is a securityescape (there are currently no examples of security escapes; this isreserved for future versions of the protocol). In either case, the length codedescribes how much data is in the record.The record length code does not include the number of bytes consumed bythe record header (2 or 3). For the 2 byte header, the record length iscomputed 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 secondbyte received. When the 3 byte header is used, the record length iscomputed 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 PADDINGvalue specifies how many bytes of data were appended to the originalrecord by the sender. The padding data is used to make the record lengthbe a multiple of the block ciphers block size when a block cipher is usedfor encryption.The sender of a "padded" record appends the padding data to the end of itsnormal data and then encrypts the total amount (which is now a multipleof the block cipher's block size). The actual value of the padding data isunimportant, but the encrypted form of it must be transmitted for thereceiver to properly decrypt the record. Once the total amount beingHickman [page 2]transmitted is known the header can be properly constructed with thePADDING value set appropriately.The receiver of a padded record decrypts the entire record data (sansrecord length and the optional padding) to get the clear data, then subtractsthe PADDING value from the RECORD-LENGTH to determine thefinal RECORD-LENGTH. The clear form of the padding data must bediscarded.4.1.1 SSL Record Data FormatThe 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 messagepayload). PADDING-DATA is the padding data sent when a block cipheris used and padding is needed. Finally, MAC-DATA is the "MessageAuthentication Code".When SSL records are sent in the clear, no cipher is used.Consequently theamount of PADDING-DATA will be zero and the amount of MAC-DATA will be zero. When encryption is in effect, the PADDING-DATAwill be a function of the cipher block size. The MAC-DATA is a functionof 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 theACTUAL-DATA, which is followed by the PADDING-DATA which isfinally followed by the SEQUENCE-NUMBER. The SEQUENCE-NUMBER is a 32 bit value which is presented to the hash function as fourbytes, with the first byte being the most significant byte of the sequencenumber, the second byte being the next most significant byte of thesequence number, the third byte being the third most significant byte, andthe fourth byte being the least significant byte (that is, in network byteorder or "big endian" order).MAC-SIZE is a function of the digest algorithm being used. For MD2 andMD5 the MAC-SIZE will be 16 bytes (128 bits).The SECRET value is a function of which party is sending the message. Ifthe client is sending the message then the SECRET is the CLIENT-WRITE-KEY (the server will use the SERVER-READ-KEY to verifythe MAC). If the client is receiving the message then the SECRET is theCLIENT-READ-KEY (the server will use the SERVER-WRITE-KEYtogenerate the MAC).Hickman [page 3]The SEQUENCE-NUMBER is a counter which is incremented by boththe sender and the receiver. For each transmission direction, a pair ofcounters is kept (one by the sender, one by the receiver). Every time amessage is sent by a sender the counter is incremented. Sequence numbersare 32 bit unsigned quantities and must wrap to zero after incrementingpast 0xFFFFFFFF.The receiver of a message uses the expected value of the sequence numberas input into the MAC HASH function (the HASH function is chosen fromthe CIPHER-CHOICE). The computed MAC-DATA must agree bit forbit with the transmitted MAC-DATA. If the comparison is not identitythen the record is considered damaged, and it is to be treated as if an "I/OError" had occurred (i.e. an unrecoverable error is asserted and theconnection is closed).A final consistency check is done when a block cipher is used and theprotocol is using encryption. The amount of data present in a record(RECORD-LENGTH))must be a multiple of the cipher's block size. Ifthe received record is not a multiple of the cipher's block size then therecord 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 isclosed).The SSL Record Layer is used for all SSL communications, includinghandshake messages, security escapes and application data transfers. TheSSL 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 thethree byte header, the maximum record length is 16383 bytes. The SSLHandshake Protocol messages are constrained to fit in a single SSL RecordProtocol record. Application protocol messages are allowed to consumemultiple SSL Record Protocol record's.Before the first record is sent using SSL all sequence numbers areinitialized to zero. The transmit sequence number is incremented afterevery message sent, starting with the CLIENT-HELLO and SERVER-HELLO messages.5. SSL Handshake Protocol Specification5.1 SSL Handshake Protocol FlowThe SSL Handshake Protocol is used to negotiate security enhancementsto data sent using the SSL Record Protocol. The security enhancementsconsist of authentication, symmetric encryption, and message integrity.The SSL Handshake Protocol has two major phases. The first phase isused to establish private communications. The second phase is used forclient authentication.5.1.1 Phase 1The first phase is the initial connection phase where both partiescommunicate their "hello" messages. The client initiates the conversationby sending the CLIENT-HELLO message. The server receives theHickman [page 4]CLIENT-HELLO message and processes it responding with theSERVER-HELLO message.At this point both the client and server have enough information to knowwhether or not a new "master key" is needed (The master key is used forproduction of the symmetric encryption session keys). When a new masterkey is not needed, both the client and the server proceed immediately tophase 2.When a new master key is needed, the SERVER-HELLO message willcontain enough information for the client to generate it. This includes theserver's signed certificate (more about that later), a list of bulk cipherspecifications (see below), and a connection-id (a connection-id is arandomly generated value generated by the server that is used by the clientand server during a single connection). The client generates the master keyand responds with a CLIENT-MASTER-KEY message (or an ERRORmessage if the server information indicates that the client and servercannot agree on a bulk cipher).It should be noted here that each SSL endpoint uses a pair of ciphers perconnection (for a total of four ciphers). At each endpoint, one cipher isused for outgoing communications, and one is used for incomingcommunications. When the client or server generate a session key, theyactually generate two keys, the SERVER-READ-KEY (also known as theCLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also knownas the CLIENT-READ-KEY). The master key is used by the client andserver to generate the various session keys (more about that later).Finally, the server sends a SERVER-VERIFY message to the client afterthe master key has been determined. This final step authenticates theserver, because only a server which has the appropriate public key canknow the master key.5.1.2 Phase 2The second phase is the client authentication phase. The server has alreadybeen authenticated by the client in the first phase, so this phase is primarilyused to authenticate the client. In a typical scenario, the server will requireauthentication of the client and send a REQUEST-CERTIFICATEmessage. The client will answer in the positive if it has the neededinformation, or send an ERROR message if it does not. This protocolspecification does not define the semantics of an ERROR response to aserver request (e.g., an implementation can ignore the error, close theconnection, etc. and still conform to this specification). In addition, it ispermissable for a server to cache client authentication information with the"session-id" cache. The server is not required to re-authenticate the clienton every connection.When a party is done authenticating the other party, it sends its finishedmessage. For the client, the CLIENT-FINISHED message contains theencrypted form of the CONNECTION-ID for the server to verify. If theverification fails, the server sends an ERROR message.Once a party has sent its finished message it must continue to listen to itspeers messages until it too receives a finished message. Once a party hasHickman [page 5]both sent a finished message and received its peers finished message, theSSL handshake protocol is done. At this point the application protocolbegins to operate (Note: the application protocol continues to be layeredon the SSL Record Protocol).5.2 Typical Protocol Message FlowThe following sequences define several typical protocol message flows forthe SSL Handshake Protocol. In these examples we have two principals inthe conversation: the client and the server. We use a notation commonlyfound 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-identifierclient-hello C -> S: challenge, cipher_specsserver-hello S -> C: connection-id, server_certificate, cipher_specsclient-master-key C -> S: {master_key}server_public_keyclient-finish C -> S: {connection-id}client_write_keyserver-verify S -> C: {challenge}server_write_keyserver-finish S -> C: {new_session_id}server_write_key5.2.2 Assuming a session-identifier was found by both client & serverclient-hello C -> S: challenge, session_id, cipher_specsserver-hello S -> C: connection-id, session_id_hitclient-finish C -> S: {connection-id}client_write_keyserver-verify S -> C: {challenge}server_write_keyserver-finish S -> C: {session_id}server_write_key5.2.3 Assuming a session-identifier was used and client authenticationis usedclient-hello C -> S: challenge, session_id, cipher_specsserver-hello S -> C: connection-id, session_id_hitclient-finish C -> S: {connection-id}client_write_keyserver-verify S -> C: {challenge}server_write_keyrequest-certificate S -> C: {auth_type,challenge'} server_write_keyclient-certificate C -> S: {cert_type,client_cert, response_data}client_write_keyserver-finish S -> C: {session_id}server_write_keyIn this last exchange, the response_data is a function of the auth_type.5.3 ErrorsError handling in the SSL connection protocol is very simple. When anerror is detected, the detecting party sends a message to the other party.Errors that are not recoverable cause the client and server to abort thesecure 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-ERRORThis error is returned by the client to the server when it cannot finda cipher or key size that it supports that is also supported by theserver. This error is not recoverable.NO-CERTIFICATE-ERRORWhen a REQUEST-CERTIFICATE message is sent, this error maybe returned if the client has no certificate to reply with. This erroris recoverable (for client authentication only).BAD-CERTIFICATE-ERRORThis error is returned when a certificate is deemed bad by thereceiving party. Bad means that either the signature of thecertificate was bad or that the values in the certificate wereinappropriate (e.g. a name in the certificate did not match theexpected name). This error is recoverable (for client authenticationonly).UNSUPPORTED-CERTIFICATE-TYPE-ERRORThis error is returned when a client/server receives a certificatetype that it can't support. This error is recoverable (for clientauthentication only).5.4 SSL Handshake Protocol MessagesThe SSL Handshake Protocol messages are encapsulated using the SSLRecord Protocol and are composed of two parts: a single byte messagetype code, and some data. The client and server exchange messages untilboth ends have sent their "finished" message, indicating that they aresatisfied with the SSL Handshake Protocol conversation. While one endmay be finished, the other may not, therefore the finished end mustcontinue 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, themessage bodies are encrypted. For the client, this happens after it verifiesthe session-identifier or creates a new master key and has sent it to theserver. For the server, this happens after the session-identifier is found tobe good, or the server receives the client's master key message.The following notation is used for SSLHP messages:char MSG-EXAMPLEchar FIELD1char FIELD2char THING-MSBchar THING-LSBchar THING-DATA[(MSB<<8)|LSB];...This notation defines the data in the protocol message, including themessage type code. The order is presented top to bottom, with the top mostelement being transmitted first, and the bottom most element transferredlast.Hickman [page 7]For the "THING-DATA" entry, the MSB and LSB values are actuallyTHING-MSB and THING-LSB (respectively) and define the number ofbytes of data actually present in the message. For example, if THING-MSB were zero and THING-LSB were 8 then the THING-DATA arraywould be exactly 8 bytes long. This shorthand is used below.Length codes are unsigned values, and when the MSB and LSB arecombined the result is an unsigned value. Unless otherwise specifiedlengths values are "length in bytes".5.5 Client Only Protocol MessagesThere are several messages that are only generated by clients. Thesemessages are never generated by correctly functioning servers. A clientreceiving such a message closes the connection to the server and returns anerror status to the application through some unspecified mechanism.5.5.1 CLIENT-HELLO (Phase 1; Sent in the clear)char MSG-CLIENT-HELLOchar CLIENT-VERSION-MSBchar CLIENT-VERSION-LSBchar CIPHER-SPECS-LENGTH-MSBchar CIPHER-SPECS-LENGTH-LSBchar SESSION-ID-LENGTH-MSBchar SESSION-ID-LENGTH-LSBchar CHALLENGE-LENGTH-MSBchar CHALLENGE-LENGTH-LSBchar 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 asits first message. It is an error for a client to send anything else as itsfirstmessage.The client sends to the server its SSL version, its cipher specs (see below),some challenge data, and the session-identifier data. The session-identifierdata is only sent if the client found a session-identifier in its cache for theserver, and the SESSION-ID-LENGTH will be non-zero. When there isno session-identifier for the server SESSION-ID-LENGTH must be zero.The challenge data is used to authenticate the server. After the client andserver 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 messageuntil it has received the CLIENT-HELLO message. This is done so thatthe server can indicate the status of the client's session-identifier back tothe client in the server's first message (i.e. to increase protocol efficiencyand reduce the number of round trips required).The server examines the CLIENT-HELLO message and will verify that itcan support the client version and one of the client cipher specs. Theserver can optionally edit the cipher specs, removing any entries it doesn'tHickman [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 amultiple of 3. The SESSION-ID-LENGTH must either be zero or 16.The CHALLENGE-LENGTH must be greater than or equal to 16 andless 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-HELLOmessage. 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-KEYchar CIPHER-KIND[3]char CLEAR-KEY-LENGTH-MSBchar CLEAR-KEY-LENGTH-LSBchar ENCRYPTED-KEY-LENGTH-MSBchar ENCRYPTED-KEY-LENGTH-LSBchar KEY-ARG-LENGTH-MSBchar KEY-ARG-LENGTH-LSBchar 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 theserver 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 theserver'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 theSECRET-KEY-DATA being the least significant bytes of the finalMASTER-KEY. The ENCRYPTED-KEY-DATA contains the secretportions 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 isbeing transmitted encrypted. The SECRET-LENGTH plus the CLEAR-KEY-LENGTH equals the number of bytes present in the cipher key (asdefined by the CIPHER-KIND). It is an error if the SECRET-LENGTHfound after decrypting the PKCS#1 formatted encryption block doesn'tmatch the expected value. It is also an error if CLEAR-KEY-LENGTH isnon-zero and the CIPHER-KIND is not an export cipher.If the key algorithm needs an argument (for example, DES-CBC'sinitialization 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 theSSL_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 andSSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARGdata 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_MD5SSL_CK_RC4_128_EXPORT40_WITH_MD5SSL_CK_RC2_128_CBC_WITH_MD5SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5SSL_CK_IDEA_128_CBC_WITH_MD5KEY-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 mostsignificant byte of the CLIENT-READ-KEY.Data is fed to the MD5 hash function in the order shown, from left toright: first the MASTER-KEY, then the "0" or "1", then theCHALLENGE 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 outputdata which are used directly as the key to the cipher algorithm (The mostsignificant byte of the MD5 output becomes the most significant byte ofthe 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-KEYwhile the remaining 8 bytes are used as the CLIENT-WRITE-KEY. Theinitialization vector is provided in the KEY-ARG-DATA. Note that theraw key data is not parity adjusted and that this step must be performedbefore the keys are legitimate DES keys.SSL_CK_DES_192_EDE3_CBC_WITH_MD5Hickman [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 toright: first the MASTER-KEY, then the "0", "1" or "2", then theCHALLENGE and then finally the CONNECTION-ID. Note that the"0" means the ascii zero character (0x30), not a zero value. "1" means theascii 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 3for the write side DES-EDE3 function. The initialization vector isprovided in the KEY-ARG-DATA. The keys that are produced are notparity adjusted. This step must be performed before proper DES keys areusable.Recall that the MASTER-KEY is given to the server in the CLIENT-MASTER-KEY message. The CHALLENGE is given to the server bythe client in the CLIENT-HELLO message. The CONNECTION-ID isgiven to the client by the server in the SERVER-HELLO message. Thismakes the resulting cipher keys a function of the original session and thecurrent session. Note that the master key is never directly used to encryptdata, 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. TheCLIENT-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-CERTIFICATEchar CERTIFICATE-TYPEchar CERTIFICATE-LENGTH-MSBchar CERTIFICATE-LENGTH-LSBchar RESPONSE-LENGTH-MSBchar RESPONSE-LENGTH-LSBchar CERTIFICATE-DATA[MSB<<8|LSB]char RESPONSE-DATA[MSB<<8|LSB]This message is sent by one an SSL client in response to a serverREQUEST-CERTIFICATE message. The CERTIFICATE-DATAcontains data defined by the CERTIFICATE-TYPE value. An ERRORmessage is sent with error code NO-CERTIFICATE-ERROR when thisrequest cannot be answered properly (e.g. the receiver of the message hasHickman [page 11]no registered certificate).CERTIFICATE-TYPE is one of:SSL_X509_CERTIFICATEThe CERTIFICATE-DATA contains an X.509 (1988) [3] signedcertificate.The RESPONSE-DATA contains the authentication response data. Thisdata is a function of the AUTHENTICATION-TYPE value sent by theserver.When AUTHENTICATION-TYPE isSSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-DATA contains a digital signature of the following components (in theorder 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 theREQUEST-CERTIFICATE message) the server's signed certificate (from the SERVER-HELLOmessage)The digital signature is constructed using MD5 and then encrypted usingthe clients private key, formatted according to PKCS#1's digital signaturestandard [5]. The server authenticates the client by verifying the digitalsignature using standard techniques. Note that other digest functions aresupported. Either a new AUTHENTICATION-TYPE can be added, orthe 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-FINISHEDchar CONNECTION-ID[N-1]The client sends this message when it is satisfied with the server. Note thatthe client must continue to listen for server messages until it receives aSERVER-FINISHED message. The CONNECTION-ID data is theoriginal connection-identifier the server sent with its SERVER-HELLOmessage, encrypted using the agreed upon session key."N" is the number of bytes in the message that was sent, so "N-1" is thenumber of bytes in the message without the message header byte.For version 2 of the protocol, the client must send this message after it hasreceived the SERVER-HELLO message. If the SERVER-HELLOmessage 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 MessagesThere are several messages that are only generated by servers. Themessages are never generated by correctly functioning clients.5.6.1 SERVER-HELLO (Phase 1; Sent in the clear)char MSG-SERVER-HELLOchar SESSION-ID-HITchar CERTIFICATE-TYPEchar SERVER-VERSION-MSBchar SERVER-VERSION-LSBchar CERTIFICATE-LENGTH-MSBchar CERTIFICATE-LENGTH-LSBchar CIPHER-SPECS-LENGTH-MSBchar CIPHER-SPECS-LENGTH-LSBchar CONNECTION-ID-LENGTH-MSBchar CONNECTION-ID-LENGTH-LSBchar 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 flagindicating whether or not the received session-identifier is known by theserver (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 theSESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE,CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields willbe zero.The CERTIFICATE-TYPE value, when non-zero, has one of the valuesdescribed above (see the information on the CLIENT-CERTIFICATEmessage).When the SESSION-ID-HIT flag is zero, the server packages up itscertificate, its cipher specs and a connection-id to send to the client. Usingthis information the client can generate a session key and return it to theserver with the CLIENT-MASTER-KEY message.When the SESSION-ID-HIT flag is non-zero, both the server and theclient compute a new pair of session keys for the current session derivedfrom the MASTER-KEY that was exchanged when the SESSION-IDwas created. The SERVER-READ-KEY and SERVER-WRITE-KEYare derived from the original MASTER-KEY keys in the same manner asthe CLIENT-READ-KEY and CLIENT-WRITE-KEY:SERVER-READ-KEY = CLIENT-WRITE-KEYSERVER-WRITE-KEY = CLIENT-READ-KEYNote that when keys are being derived and the SESSION-ID-HIT flag isset and the server discovers the client's session-identifier in the serverscache, then the KEY-ARG-DATA is used from the time when theHickman [page 13]
SESSION-ID was established. This is because the client does not sendnew KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only inthe CLIENT-MASTER-KEY message).The CONNECTION-ID-DATA is a string of randomly generated bytesused by the server and client at various points in the protocol. TheCLIENT-FINISHED message contains an encrypted version of theCONNECTION-ID-DATA. The length of the CONNECTION-ID mustbe 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 3bytes long and looks like this:char CIPHER-KIND-0char CIPHER-KIND-1char CIPHER-KIND-2Where CIPHER-KIND is one of:SSL_CK_RC4_128_WITH_MD5SSL_CK_RC4_128_EXPORT40_WITH_MD5SSL_CK_RC2_128_CBC_WITH_MD5SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5SSL_CK_IDEA_128_CBC_WITH_MD5SSL_CK_DES_64_CBC_WITH_MD5SSL_CK_DES_192_EDE3_CBC_WITH_MD5This list is not exhaustive and may be changed in the future.The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4cipher where some of the session key is sent in the clear and the rest is sentencrypted (exactly 40 bits of it). MD5 is used as the hash function forproduction of MAC's and session key's. This cipher type is provided tosupport "export" versions (i.e. versions of the protocol that can bedistributed outside of the United States) of the client or server.An exportable implementation of the SSL Handshake Protocol will havesecret key lengths restricted to 40 bits. For non-export implementationskey lengths can be more generous (we recommend at least 128 bits). It ispermissible for the client and server to have a non-intersecting set ofstream ciphers. This, simply put, means they cannot communicate.Version 2 of the SSL Handshake Protocol defines theSSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. TheSSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of128 bits. However, only 40 of the bits are secret (the other 88 bits are sentin the clear by the client to the server).The SERVER-HELLO message is sent after the server receives theCLIENT-HELLO message, and before the server sends the SERVER-VERIFY message.5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted)char MSG-SERVER-VERIFYHickman [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 eitherby a session-identifier or by explicit specification with the CLIENT-MASTER-KEY message. The message contains an encrypted copy of theCHALLENGE-DATA sent by the client in the CLIENT-HELLOmessage."N" is the number of bytes in the message that was sent, so "N-1" is thenumber of bytes in the CHALLENGE-DATA without the messageheader byte.This message is used to verify the server as follows. A legitimate serverwill have the private key that corresponds to the public key contained inthe server certificate that was transmitted in the SERVER-HELLOmessage. Accordingly, the legitimate server will be able to extract andreconstruct the pair of session keys (SERVER-READ-KEY andSERVER-WRITE-KEY). Finally, only a server that has done theextraction and decryption properly can correctly encrypt theCHALLENGE-DATA. This, in essence, "proves" that the server has theprivate key that goes with the public key in the server's certificate.The CHALLENGE-DATA must be the exact same length as originallysent by the client in the CLIENT-HELLO message. Its value must matchexactly the value sent in the clear by the client in the CLIENT-HELLOmessage. The client must decrypt this message and compare the valuereceived with the value sent, and only if the values are identical is theserver to be "trusted". If the lengths do not match or the value doesn'tmatch then the connection is to be closed by the client.This message must be sent by the server to the client after either detectinga session-identifier hit (and replying with a SERVER-HELLO messagewith SESSION-ID-HIT not equal to zero) or when the server receives theCLIENT-MASTER-KEY message. This message must be sent beforeany Phase 2 messages or a SERVER-FINISHED message.5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted)char MSG-SERVER-FINISHEDchar SESSION-ID-DATA[N-1]The server sends this message when it is satisfied with the clients securityhandshake and is ready to proceed with transmission/reception of thehigher level protocols data. The SESSION-ID-DATA is used by the clientand the server at this time to add entries to their respective session-identifier caches. The session-identifier caches must contain a copy of theMASTER-KEY sent in the CLIENT-MASTER-KEY message as themaster 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 thenumber of bytes in the SESSION-ID-DATA without the message headerbyte.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-CERTIFICATEchar AUTHENTICATION-TYPEchar CERTIFICATE-CHALLENGE-DATA[N-2]A server may issue this request at any time during the second phase of theconnection handshake, asking for the client's certificate. The clientresponds with a CLIENT-CERTIFICATE message immediately if it hasone, or an ERROR message (with error code NO-CERTIFICATE-ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is ashort byte string (whose length is greater than or equal to 16 bytes and lessthan or equal to 32 bytes) that the client will use to respond to thismessage.The AUTHENTICATION-TYPE value is used to choose a particularmeans of authenticating the client. The following types are defined:SSL_AT_MD5_WITH_RSA_ENCRYPTIONThe SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that theclient construct an MD5 message digest using information as describedabove in the section on the CLIENT-CERTIFICATE message. Once thedigest is created, the client encrypts it using its private key (formattedaccording to the digital signature standard defined in PKCS#1). The serverauthenticates the client when it receives the CLIENT-CERTIFICATEmessage.This message may be sent after a SERVER-VERIFY message and beforea SERVER-FINISHED message.5.7 Client/Server Protocol MessagesThese messages are generated by both the client and the server.5.7.1 ERROR (Sent clear or encrypted)char MSG-ERRORchar ERROR-CODE-MSBchar ERROR-CODE-LSBThis message is sent when an error is detected. After the message is sent,the sending party shuts the connection down. The receiving party recordsthe error and then shuts its connection down.This message is sent in the clear if an error occurs during session keynegotiation. After a session key has been agreed upon, errors are sentencrypted like all other messages.Appendix A: ASN.1 Syntax For CertificatesCertificates are used by SSL to authenticate servers and clients. SSLCertificates are based largely on the X.509 [3] certificates. An X.509certificate 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 ::= INTEGERValidity ::= 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 andCertificateInfo::signature fields must be identical in value. The issuer name must resolve to a name that is deemed acceptable bythe application using SSL. How the application using SSL does this isoutside the scope of this memo.Certificates are validated using a few straightforward steps. First, thesignature on the certificate is checked and if invalid, the certificate isinvalid (either a transmission error or an attempted forgery occurred).Next, the CertificateInfo::issuer field is verified to be an issuer that theapplication trusts (using an unspecified mechanism). TheCertificateInfo::validity field is checked against the current date andverified.Finally, the CertificateInfo::subject field is checked. This check isoptional and depends on the level of trust required by the application usingSSL.Hickman [page 17]Appendix B: Attribute Types and Object IdentifiersSSL uses a subset of the X.520 selected attribute types as well as afew specific object identifiers. Future revisions of the SSL protocolmay include support for more attribute types and more objectidentifiers.B.1 Selected attribute typescommonName { attributeType 3 }The common name contained in the distinguished name containedwithin a certificate issuer or certificate subject.countryName { attributeType 6 }The country name contained in the distinguished name containedwithin a certificate issuer or certificate subject.localityName { attributeType 7 }The locality name contained in the distinguished name containedwithin a certificate issuer or certificate subject.stateOrProvinceName { attributeType 8 }The state or province name contained in the distinguished namecontained within a certificate issuer or certificate subject.organizationName { attributeType 10 }The organization name contained in the distinguished name containedwithin a certificate issuer or certificate subject.organizationalUnitName { attributeType 11 }The organizational unit name contained in the distinguished namecontained within a certificate issuer or certificate subject.B.2 Object identifiersmd2withRSAEncryption { ... pkcs(1) 1 2 }The object identifier for digital signatures that use both MD2 and RSAencryption. Used by SSL for certificate signature verification.md5withRSAEncryption { ... pkcs(1) 1 4 }The object identifier for digital signatures that use both MD5 and RSAencryption. Used by SSL for certificate signature verification.rc4 { ... rsadsi(113549) 3 4 }The RC4 symmetric stream cipher algorithm used by SSL for bulkencryption.Appendix C: Protocol Constant ValuesThis section describes various protocol constants. A special value needsmentioning - the IANA reserved port number for "https" (HTTP usingSSL). IANA has reserved port number 443 (decimal) for "https". IANAhas 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 0x0002C.2 Protocol Message CodesThe following values define the message codes that are used by version2 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 8C.3 Error Message CodesThe 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 0x0006C.4 Cipher Kind ValuesThe following values define the CIPHER-KIND codes used in theCLIENT-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,0xC0C.5 Certificate Type CodesThe following values define the certificate type codes used in theSERVER-HELLO and CLIENT-CERTIFICATE messages.#define SSL_CT_X509_CERTIFICATE 0x01Hickman [page 19]
C.6 Authentication Type CodesThe following values define the authentication type codes used in theREQUEST-CERTIFICATE message.#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01C.7 Upper/Lower BoundsThe following values define upper/lower bounds for various protocolparameters.#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 16383C.8 RecommendationsBecause protocols have to be implemented to be of value, we recommendthe following values for various operational parameters. This is only arecommendation, and not a strict requirement for conformance to theprotocol.Session-identifier Cache TimeoutSession-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 singleclient/server pairing). Consequently, we recommend a maximum session-identifier cache timeout value of 100 seconds. Given a server that canperform N private key operations per second, this reduces the server loadfor a particular client by a factor of 100.Appendix D: AttacksIn this section we attempt to describe various attacks that might be usedagainst the SSL protocol. This list is not guaranteed to be exhaustive. SSLwas defined to thwart these attacks.D.1 Cracking CiphersSSL depends on several cryptographic technologies. RSA Public Keyencryption [5] is used for the exchange of the session key and client/serverauthentication. Various cryptographic algorithms are used for the sessioncipher. If successful cryptographic attacks are made against thesetechnologies then SSL is no longer secure.Attacks against a specific communications session can be made byrecording the session, and then spending some large number of computecycles to crack either the session key or the RSA public key until thecommunication can be seen in the clear. This approach is easier thancracking the cryptographic technologies for all possible messages. Notethat SSL tries to make the cost of such of an attack greater than theHickman [page 20]
benefits gained from a successful attack, thus making it a waste ofmoney/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 AttackA clear text attack is done when the attacker has an idea of what kind ofmessage is being sent using encryption. The attacker can generate a database 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 thesession key that goes with a particular encrypted value. Once the sessionkey is known, the entire message stream can be decrypted. Customhardware can be used to make this cost effective and very fast.Because of the very nature of SSL clear text attacks are possible. Forexample, the most common byte string sent by an HTTP client applicationto an HTTP server is "GET". SSL attempts to address this attack by usinglarge session cipher keys. First, the client generates a key which is largerthan allowed by export, and sends some of it in the clear to the server (thisis allowed by United States government export rules). The clear portion ofthe key concatenated with the secret portion make a key which is verylarge (for RC4, exactly 128 bits).The way that this "defeats" a clear text attack is by making the amount ofcustom hardware needed prohibitively large. Every bit added to the lengthof the session cipher key increases the dictionary size by a factor of 2. Byusing a 128 bit session cipher key length the size of the dictionary requiredis beyond the ability of anyone to fabricate (it would require more atoms toconstruct than exist in the entire universe). Even if a smaller dictionary isto be used, it must first be generated using the clear key bits. This is a timeconsumptive process and also eliminates many possible custom hardwarearchitectures (e.g. static prom arrays).The second way that SSL attacks this problem is by using large keylengths when permissible (e.g. in the non-export version). Large key sizesrequire larger dictionaries (just one more bit of key size doubles the size ofthe 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 attackbecomes the cheapest way to attack the key. Brute force attacks have wellknown space/time tradeoffs and so it becomes possible to define a cost ofthe 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 therange of the "random hacker".D.3 ReplayThe replay attack is simple. A bad-guy records a communication sessionbetween a client and server. Later, it reconnects to the server, and playsback the previously recorded client messages. SSL defeats this attackusing a "nonce" (the connection-id) which is "unique" to the connection. Intheory the bad-guy cannot predict the nonce in advance as it is based on aHickman [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 clientand a server, and attempt to choose the right session based on the noncethe server sends initially in its SERVER-HELLO message. However, SSLnonces are at least 128 bits long, so a bad-guy would need to recordapproximately 2^64 nonces to even have a 50% chance of choosing theright session. This number is sufficiently large that one cannoteconomically construct a device to record 2^64 messages, and thereforethe odds are overwhelmingly against the replay attack ever beingsuccessful.D.4 The Man In The MiddleThe man in the middle attack works by having three people in acommunications session: the client, the server, and the bad guy. The badguy sits between the client and the server on the network and interceptstraffic that the client sends to the server, and traffic that the serversends tothe client.The man in the middle operates by pretending to be the real server to theclient. With SSL this attack is impossible because of the usage of servercertificates. During the security connection handshake the server isrequired 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 nameand the name of the certificate issuer. The client verifies the certificate byfirst checking the signature and then verifying that the name of the issueris somebody that the client trusts.In addition, the server must encrypt something with the private key thatgoes with the public key mentioned in the certificate. This in essence is asingle pass "challenge response" mechanism. Only a server that has boththe certificate and the private key can respond properly to the challenge.If the man in the middle provides a phony certificate, then the signaturecheck will fail. If the certificate provided by the bad guy is legitimate, butfor the bad guy instead of for the real server, then the signature will passbut the name check will fail (note that the man in the middle cannot forgecertificates without discovering a certificate authority's private key).Finally, if the bad guy provides the real server's certificate then thesignature check will pass and the name check will pass. However, becausethe bad guy does not have the real server's private key, the bad guy cannotproperly encode the response to the challenge code, and this check willfail.In the unlikely case that a bad guy happens to guess the response code tothe challenge, the bad guy still cannot decrypt the session key andtherefore cannot examine the encrypted data.Hickman [page 22]Appendix E: TermsApplication ProtocolAn application protocol is a protocol that normally layers directly ontop of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP.AuthenticationAuthentication is the ability of one entity to determine the identity ofanother entity. Identity is defined by this document to mean thebinding between a public key and a name and the implicit ownershipof the corresponding private key.Bulk CipherThis term is used to describe a cryptographic technique with certainperformance properties. Bulk ciphers are used when large quantities ofdata are to be encrypted/decrypted in a timely manner. Examplesinclude RC2, RC4, and IDEA.ClientIn this document client refers to the application entity that is initiates aconnection to a server.CLIENT-READ-KEYThe 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-KEYThe session key that the client uses to initialize the client write cipher.This key has the same value as the SERVER-READ-KEY.MASTER-KEYThe master key that the client and server use for all session keygeneration. The CLIENT-READ-KEY, CLIENT-WRITE-KEY,SERVER-READ-KEY and SERVER-WRITE-KEY are generatedfrom the MASTER-KEY.MD2MD2 [8] is a hashing function that converts an arbitrarily long datastream into a digest of fixed size. This function predates MD5 [7]which is viewed as a more robust hash function [9].MD5MD5 [7] is a hashing function that converts an arbitrarily long datastream into a digest of fixed size. The function has certain propertiesthat make it useful for security, the most important of which is it'sinability to be reversed.NonceA randomly generated value used to defeat "playback" attacks. Oneparty randomly generates a nonce and sends it to the other party. Thereceiver encrypts it using the agreed upon secret key and returns it tothe sender. Because the nonce was randomly generated by the senderthis defeats playback attacks because the replayer can't know inadvance the nonce the sender will generate. The receiver deniesconnections that do not have the correctly encrypted nonce.Hickman [page 23]
Non-repudiable Information ExchangeWhen two entities exchange information it is sometimes valuable tohave a record of the communication that is non-repudiable. Neitherparty can then deny that the information exchange occurred. Version 2of the SSL protocol does not support Non-repudiable informationexchange.Public Key EncryptionPublic key encryption is a technique that leverages asymmetric ciphers.A public key system consists of two keys: a public key and a privatekey. Messages encrypted with the public key can only be decryptedwith the associated private key. Conversely, messages encrypted withthe private key can only be decrypted with the public key. Public keyencryption tends to be extremely compute intensive and so is notsuitable as a bulk cipher.PrivacyPrivacy is the ability of two entities to communicate without fear ofeavesdropping. Privacy is often implemented by encrypting thecommunications stream between the two entities.RC2, RC4Proprietary bulk ciphers invented by RSA (There is no good referenceto these as they are unpublished works; however, see [9]). RC2 isblock cipher and RC4 is a stream cipher.ServerThe server is the application entity that responds to requests forconnections from clients. The server is passive, waiting for requestsfrom clients.Session cipherA session cipher is a "bulk" cipher that is capable of encrypting ordecrypting arbitrarily large amounts of data. Session ciphers are usedprimarily for performance reasons. The session ciphers used by thisprotocol are symmetric. Symmetric ciphers have the property of usinga single key for encryption and decryption.Session identifierA session identifier is a random value generated by a client thatidentifies itself to a particular server. The session identifier can bethought of as a handle that both parties use to access a recorded secretkey (in our case a session key). If both parties remember the sessionidentifier then the implication is that the secret key is already knownand need not be negotiated.Session keyThe key to the session cipher. In SSL there are four keys that are calledsession keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,SERVER-READ-KEY, and SERVER-WRITE-KEY.SERVER-READ-KEYThe 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-KEYThe session key that the server uses to initialize the server write cipher.This key has the same value as the CLIENT-READ-KEY.Symmetric CipherA symmetric cipher has the property that the same key can be used fordecryption and encryption. An asymmetric cipher does not have thisbehavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.References[1] CCITT. Recommendation X.208: "Specification of Abstract SyntaxNotation One (ASN.1). 1988.[2] CCITT. Recommendation X.209: "Specification of Basic EncodingRules for Abstract Syntax Notation One (ASN.1). 1988.[3] CCITT. Recommendation X.509: "The Directory - AuthenticationFramework". 1988.[4] CCITT. Recommendation X.520: "The Directory - Selected AttributeTypes". 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. April1992.[8] R. Rivest.RFC 1319: The MD2 Message Digest Algorithm. April1992.[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and SourceCode in C, Published by John Wiley & Sons, Inc. 1994.[10] M. Abadi and R. Needham. Prudent engineering practice forcryptographic protocols. 1994.Patent StatementThis version of the SSL protocol relies on the use of patented public keyencryption technology for authentication and encryption. The InternetStandards Process as defined inRFC 1310 requires a written statementfrom the Patent holder that a license will be made available to applicantsunder reasonable terms and conditions prior to approving a specification asa Proposed, Draft or Internet Standard.The Massachusetts Institute of Technology and the Board of Trustees ofthe Leland Stanford Junior University have granted Public Key Partners(PKP) exclusive sub-licensing rights to the following patents issued in theHickman [page 25]
United States, and all of their corresponding foreign patents:Cryptographic Apparatus and Method ("Diffie-Hellman") No. 4,200,770Public Key Cryptographic Apparatus and Method ("Hellman-Merkle") No. 4,218,582Cryptographic Communications System and Method ("RSA") No. 4,405,829Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig") No. 4,424,414These patents are stated by PKP to cover all known methods of practicingthe art of Public Key encryption, including the variations collectivelyknown as ElGamal.Public Key Partners has provided written assurance to the Internet Societythat parties will be able to obtain, under reasonable, nondiscriminatoryterms, the right to use the technology covered by these patents. Thisassurance is documented inRFC 1170 titled "Public Key Standards andLicenses". A copy of the written assurance dated April 20, 1990, may beobtained from the Internet Assigned Number Authority (IANA).The Internet Society, Internet Architecture Board, Internet EngineeringSteering Group and the Corporation for National Research Initiatives takeno position on the validity or scope of the patents and patent applications,nor on the appropriateness of the terms of the assurance. The InternetSociety and other groups mentioned above have not made anydetermination as to any other intellectual property rights which may applyto the practice of this standard. Any further consideration of these mattersis the user's own responsibility.Security ConsiderationsThis entire document is about security.Author's AddressKipp E.B. HickmanNetscape Communications Corp.501 East Middlefield Rd.Mountain View, CA 94043kipp@netscape.comHickman [page 26] draft-hickman-netscape-ssl-00
Expired Internet-Draft (individual)
| Document | Document type | Expired Internet-Draft (individual) Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Authors | Dr. Taher Elgamal,Kipp E.B. Hickman Email authors | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Other formats |