diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-ssl-mods-00.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-ssl-mods-00.txt | 224 |
1 files changed, 0 insertions, 224 deletions
diff --git a/doc/protocol/draft-ietf-tls-ssl-mods-00.txt b/doc/protocol/draft-ietf-tls-ssl-mods-00.txt deleted file mode 100644 index 1a068269ee..0000000000 --- a/doc/protocol/draft-ietf-tls-ssl-mods-00.txt +++ /dev/null @@ -1,224 +0,0 @@ -Transport Layer Security Working Group Tim Dierks -INTERNET-DRAFT Consensus Development -Expires May 31, 1997 November 26, 1996 - - - Modifications to the SSL protocol for TLS - <draft-ietf-tls-ssl-mods-00.txt> - - - -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 made obsolete 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). - - -Abstract - -This document recommends for several modifications be made to the SSL -3.0 protocol as it is standardized by the IETF under the name of TLS. -These changes primarily standardize various technical details of the -protocol and make some other minor modifications. - -1. MAC algorithm - -SSL 3.0 uses a version of the HMAC algorithm which is not the most -recent or the recommended standard. The SSL MAC is defined as: - - hash(MAC_secret + pad_2 + - hash(MAC_secret + pad_1 + data)); - -Where data is the concatenation of several record header fields and the -record data. pad_1 and pad_2 are repetitions of the value 0x36 and 0x5C, -respectively. These bytes are repeated a number of times dependent on -which hash algorithm is being used: 48 times for MD5 and 40 times for -SHA. - -I recommend moving to HMAC as described in -<draft-ietf-ipsec-hmac-md5-01.txt> by incorporating this algorithm into -the TLS standard (or by referring to it, should it become an RFC -standard). This formulation uses a 64 byte pad which is combined with -the MAC secret using XOR rather than concatenation. - -Dierks, T. Expires May, 1997 [Page 1] - INTERNET-DRAFT SSL-TLS mods November 1996 - -This would replace the MAC formulations used in the certificate verify -and finished messages (where the MAC_secret is the master secret) and -the MAC formulation used in the record layer (where the MAC_secret is -generated specifically for each connection direction.) - -2. MAC contents - -Currently, the SSL record layer applies the MAC to every element in the -record except for the protocol version encoded into every packet. It is -inappropriate to transmit values which might affect the functionality of -the connection without applying the MAC to these values. If the version -number does not control the function of the channel, it should be -eliminated; if it does affect the communication, it should be MACed. -Thus, I recommend that the data which is MAC`d be amended to: - - seq_num + SSLCompressed.type + SSLCompressed.version + - SSLCompressed.length + SSLCompressed.fragment - -3. Block padding - -Padding is required when working with block ciphers to expand source -data to an even multiple of the block length. SSL specifies padding, but -does not specify a particular value. In order to ensure that -implementors do not accidentally transmit unintended data in -uninitialized padding fields, I recommend that the TLS add a requirement -that the padding be initialized to a particular value. I propose that -the padding field must be zeroed and that implementations should check -for appropriate padding on incoming records. - -4. Message order standardization - -In the original SSL 3.0 specification, an error made the statement of -when the certificate request message should be transmitted unclear, and -different implementations send it in two places: either before or after -the server key exchange message. I propose that for the TLS -specification, the certificate request message be clearly specified to -follow the server key exchange message. - -5. Certificate chain contents - -In the original SSL 3.0 specification, the text required that a complete -X.509 certificate chain be sent up to and including the self-signed root -cert. It is claimed that this was not the intent of the drafters, and in -fact, many implementations do not comply with this portion of the -standard. Thus, I propose that the TLS specification clearly state that -a partial certificate chain is acceptable if it can be reasonably hoped -that the peer will hold all needed certificates to complete the chain. - - - - - - -Dierks, T. Expires May, 1997 [Page 2] - INTERNET-DRAFT SSL-TLS mods November 1996 - -6. The no_certificate alert - -The no_certificate alert, which is to be sent by a client which does not -have a suitable certificate to provide a server, presents a subtle -problem to the SSL implementer. Because the message order of the SSL -protocol is for the most part well defined and enforced, what messages -have arrived is very important to the state machine which manages the -handshake protocol. Because this alert can replace a handshake message, -the alert protocol must communicate to the handshake protocol that this -alert has arrived. This is the only place where such a piece of -promiscuity is required, thus I recommend that in place of sending a -no_certificate alert, TLS clients who do not have a suitable certificate -for a server submit instead an Certificate message which contains no -certificates. - -7. Additional alerts - -SSL doesn`t have a great deal of variety in its error alerts. I propose -that the following alerts be added to the specification: - - internal_error [fatal]: an internal error unrelated to the peer or -the correctness of the protocol makes it impossible to continue (such as -a memory allocation failure). - user_canceled [fatal]: the user aborted this handshake or connection -for some reason. - decrypt_error [fatal]: a public or private key operation failed due -to using the wrong key - decode_error [fatal]: a message could not be decoded because some -field was out of the specified range or the length of the message was -incorrect. - export_restriction [fatal]: an attempt to circumvent export -restrictions was detected; for example, attemption to transfer a 1024 -bit ephemeral RSA key for the RSA_EXPORT handshake method. - protocol_version [fatal]: the protocol version the peer has -attempted to negotiate is recognized, but not supported. (For example, -old protocol versions might be avoided for security reasons). - record_overflow [fatal]: an SSLCiphertext record was received which -had a length more than 2^14+2048 bytes, or a record decrypted to a -SSLCompressed record with more than 2^14+1024 bytes. - decryption_failed [fatal]: a SSLCiphertext decrypted in an invalid -way: either it wasn`t an even multiple of the block length or its -padding values, when checked, weren`t correct. - access_denied [fatal]: a valid certificate was received, but it did -not pass the access control mechanism. - unknown_ca [fatal]: a valid certificate chain or partial chain was -received, but the certificate was not accepted because the CA -certificate could not be located or couldn`t be matched with a known, -trusted CA. - insufficient_security [fatal]: returned instead of handshake_failure -when a negotiation has failed specifically because one of the parties -requires ciphers more secure than those supported by their peer. - no_renegotiation [warning]: generated in response to a hello request - -Dierks, T. Expires May, 1997 [Page 3] - INTERNET-DRAFT SSL-TLS mods November 1996 - -or a client hello sent on an already negotiated channel. This informs -the requestor that no response will be generated, as this entity does -not want to renegotiate security parameters (as you might wish to do if -there` no way to communicate security parameters up the stack to the -client after initial negotiation. - -8. Seperation of Record and Handshake layers - -The SSL Record Protocol and Handshake Protocol can be viewed as two -independant layered protocols: the Record Protocol provides encrypted, -reliable transport, and the Handshake Protocol provides algorithm and -key negotiation and peer authentication. I propose that they be formally -seperated into two documents, or at least two distinct sections of the -TLS document. This should make their interoperation clearer, aiding -security analysis and perhaps allowing utilization of the Record -Protocol with some other handshake protocol or vice-versa. - -9. Additional Record Protocol clients - -The SSL Record Protocol supports transmitting many different kinds of -records over a single connection. This is already used for -distinguishing different kinds of protocol messages from each other and -from application data. I propose that TLS clearly specify that layered -protocols are allowed to use the Record Protocol to transport new record -types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dierks, T. Expires May, 1997 [Page 4] |