Network Working Group L. Joncheray INTERNET DRAFT Merit <draft-joncheray-encryption-00.html> May 1995 Expires November 1995 Public Key Encryption Support for TCP 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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents a set of proposed modifications and extensions for the TCP protocol in order to support Public Key Encryption schemes. It introduces two new options for the TCP header as well as a minor modification of the semantic of bits 4 to 7, byte 12 of the TCP header. The proposal is designed to provide compatibility with older versions of TCP that do not incorporate those extensions. 1. Introduction One major flaw of the TCP protocol is a lack of built-in authentication and encryption capabilities. These restrictions have being widely used on the internet to spoof and break into hosts or to perform 'refusal of service' attacks. Usually users bypass such limitations by providing encryption and authentication at an upper layer of TCP. Kerberos is one of the currently available option. However this upper layer approach does not solve all the security problems of TCP and allow the connection to be still vulnerable to attacks (refusal of service is the easiest to conduct). This memo discusses an implementation of a Public Key Encryption scheme at the TCP layer. This extension provides the user with host based authentication and/or encryption of the data stream. Applications do no longer need to protect themselves again a third party attack. The authentication scheme proposed here is based on the RSA Public Key algorithm and IDEA block cipher. The first section briefly presents the general principles of Public Key Encryption algorithms. The second section describes the integration of this algorithm into TCP. And finally the last section lists the proposed modifications and extensions to the TCP protocol standard. 2. Public Key Encryption. RSA and IDEA algorithms A detailed description of the RSA and IDEA algorithms can be found in [SCHNEIER94]. Also an introduction to Public Key encryption or signature is available in [SCHNEIER94] and [RFC1704]. Briefly, the data is encrypted using the IDEA block cipher in CFB mode (a la Zimmermann, C.f. [PGP]). The 128 bits long secret key needed to encrypt is exchanged during the session establishment in using the RSA public key algorithm. The key is encrypted with the public key, sent to the peer, and only the peer can decrypt it with its secret key. 3. Integration of RSA/IDEA into TCP The integration of the RSA algorithm into TCP has been done in term of client-server relationships. The end point that opens the connection will be referred to as the client, and the end point accepting the connection will be referred to as the server. Each end of the connection keeps two 128 bits long IDEA keys: one for encrypting the data sent (snd key). one for decrypting the data received (rcv key). The snd key is generated by the peer, and transmitted to the host by using the TCPOPT_CRYPT option (C.f. Section 4). The rcv key is generated by the host and sent to the peer in a TCPOPT_CRYPT option. In other words, the client uses the server's generated IDEA key to encrypt or sign its segments. The server uses the IDEA key generated by the client to encrypt or sign its segments. The establishment stage of the TCP connection is used by the parties to exchange their IDEA keys by using the RSA Public Key encryption scheme. If one host does not know the peer's public key and so cannot generate a TCPCRYPT option then the same key is used for sending or receiving data: If we suppose that host A has host B public key, but host B does not have host A public key then host A generates the IDEA key, sends it to host B, and both hosts A and B use that key for sending or receiving data. Once in the ESTABLISHED state any incoming packet must be signed in order to be acceptable. A certificate is appended to each segment by using the TCPOPT_CERT option (C.f. Section 4). The certificate is obtained by the following method: The host generates a 64 bit long random number. A MD5 checksum of the 64 random bits, the 128 first bits of the TCP header, the data (if presents) is computed. The resulting 64 first bits (of 128) are appended to the 64 bits random number. This is 128 bits. The 128 bits are encrypted using the peer's idea key (snd key). The result constitutes the certificate (128 bits). On receipt of this certificate the peer goes through the following steps to check the validity of the certificate: The 128 bits are decrypted using its rcv key. The MD5 checksum is computed as described previously. The result is compared with the 64 last bits of the decrypted cer- tificate (step one). If the comparison fails the certificate is assumed to be wrong. The TCP integration proposes two levels of security and three levels of quality of service (QOS). The two levels of security are Signature of the segments only (called TCP_SIGN option), and Signature and Encryption of the segments (called TCP_CRYPT option). The three levels of quality of service are: TWOWAYS: The client must authenticate itself to the server and the server must authenticate itself to the client. Both parties will generate their own IDEA encryption key. ONEWAY: At least one of the parties has to authenticate itself to the other one. At least one IDEA encryption key will be generated. TGUP: (Try or Give up) The parties will try to authenticate them- selves to the other but no guarantee of success is pro- vided. For instance if none of the parties has the other's public key then neither authentication nor encryption is possible. TWOWAYS QOS is recommended for TCP sessions where both the client and the server want to identify the other end. For instance a telnet ses- sion between two secure hosts. ONEWAY QOS is recommended for public server based TCP session. The server is a well know host with a widely available public key. The client can be anybody on the network. The server authenticates itself to the client. The client is guaranteed to be connected to the server. For example a public FTP server cite will use a ONEWAY QOS. The option is also useful when the client's IP address is not known in advance (e.g. computers using a PPP server) TGUP QOS is used when one wants to encrypt or sign the TCP session but is not sure if the other end supports the encryption or signature scheme. In this case a normal TCP session will take place. The following table summarizes the different cases of connection depending on the quality of service and the availability of the peer's public key. The first row/first columns are the QOS of the client/server. The 'NONE' means RFC 793 TCP (The new options are not used nor under- stood). The second row/second column is 'Yes' if the peer's public key is known, 'No' if the peer's public key is unknown. Hosts with a 'NONE' QOS do not know the peer's public key since they are not sup- posed to implement the crypted TCP. The rest of the table lists the type of TCP connection allowed. Client | TWOWAYS | ONEWAY | TGUP | NONE Server | No Yes | No Yes | No Yes | No -------------+---------------+---------------+----------------+------- TWOWAYS No | Drop Drop | Drop Drop | Drop Drop | Drop Yes | Drop 2-Ways | Drop 2-Ways | Drop 2-Ways | Drop -------------+---------------+---------------+----------------+------- ONEWAY No | Drop Drop | Drop 1-Way | Drop 1-Way | Drop Yes | Drop 2-Ways | 1-Way 2-Ways | 1-Way 2-Ways | Drop -------------+---------------+---------------+----------------+------- TGUP No | Drop Drop | Drop 1-Way | Normal 1-Way | Normal Yes | Drop 2-Ways | 1-Way 2-Ways | 1-Way 2-Ways | Normal -------------+---------------+---------------+----------------+------- NONE No | Drop Drop | Drop Drop | Normal Normal | Normal Drop: Drop the connection 1-Way: Encrypted connection. The hosts share one key. 2-Ways: Encrypted connection. Two IDEA keys are used. Normal: No encryption (Normal TCP connection). If the TCP_CRYPT service is used the data is crypted using the IDEA cipher block in CFB mode. Moreover the 256 first bytes of the connec- tion are scrambled using a pseudo-random number generator. The algo- rithm is: Divide the 128 bits IDEA key into four 32 bits integer i0, i1, i2, i3.. Compute Seed = i0 - i1 - i2 -i3 (mod 2^32). Generate a set U(n) of 32 bits integer: U(0) = Seed; U(n+1) = (9301 * U(n) + 49297) mod(233280) XOR the 256 first bytes of the data steam with the 256 first value of the set. The 128 bit session key should be randomly generated for any new TCP connection. The way the key is computed is unspecified. 4. Extension and modification to TCP The implementation of this scheme relies on the use of two new TCP options: TCPOPT_CRYPT which contains the IDEA public key encrypted key used for signature or encryption by the peer; TCPOPT_CERT which contains a certificate (or signature) which certifies that the TCP segment is from the peer. The format for the TCPOPT_CRYPT option is: +-------------+-------------+-------------+-------------+ | Kind=10 | Length | | | +-------------+-------------+-------------+-------------+ | .... | +-------------+-------------+-------------+-------------+ : : | ... | +-------------+-------------+-------------+-------------+ The 'Length' field is equal to 4 plus the length of the RSA encrypted IDEA key. If the host cannot get the peer's public key the length of the RSA encrypted IDEA key is set to zero and the field does not exist. is a one byte length field describing the type of security wanted. If the bit 7 is set then the lenght of the field must be null. If the bit 6 is set then only signature of the packets are requested. is the type of algorithm used for encryption or signature. Only IDEA is defined now. The format for the TCPOPT_CERT is +-------------+-------------+------------ ..... -------+ | Kind=11 | Length=18 | <16 bytes certificate> | +-------------+-------------+------------ ..... -------+ is the certificate obtained using the method described in Section 3. The field of the TCPOPT_CRYPT option can be as long as 1024 bits (128 bytes) with the current implementation. In order to support TCP header longer than 15*4 = 60 bytes long (current standard with a Data Offset field of 4 bits) the Data Offset field has been extented to 8 bits. That allow 255*4 = 1020 bytes long TCP header. The extension is the following: bit 0 to 3 of the Data Offset (LSB) go into the old TCP Data Offset field. bit 4 to 7 of the Data Offset (MSB) go into the bits 4 to 7 of byte 12 of the TCP header. These bits are defined as reserved in RFC 793 and should be set to zero in the old TCP. Those characteristics make the standard Data Offset compatible with the extented Data Offset. A secure TCP implementation can still receive standard TCP packets. A standard TCP implementation will drop any packet with a extented Data Offset since it violates the proto- col. 5. Security Considerations Have you not had enough? 6. Conclusion Performance is a major concern in the design and implementation of a secure transport protocol. Current implementation of the secure TCP options are fast enough for an interactive session where the traffic is pretty low. For applications like file transfer (FTP) or Elec- tronic mail the overhead caused by the cryptographic algorithm may prevent one from using it. Key management of the public keys is another problem which need to be addressed. A internal key ring can be kept by each host as long as the number of parties is small, but this scheme does not scale for hundred of hosts talking to each other. Small interactive sessions where the traffic is pretty low are par- ticularly well suited for this TCP encryption scheme. The degradation of the throughput does not impact the user too much. [Author's experiment: 8KBps (64Kbps) on a sun sparc LX - 50 MHz microSPARC CPU] 7. Author's Address Laurent P. Joncheray Merit Network, Inc. 4251 Plymouth Rd, Suite C, Ann Arbor MI 48105 USA Phone: +1 (313) 936 2065 Fax: +1 (313) E-mail: lpj@merit.edu 8. References. [IDEA], [RSA], [SCHNEIER94] B. Schneier, "Applied Cryptography", John Wiley & Sons, Inc., ISBN 0-471-59756-2, 1994. INTERNET DRAFT Public Key Encryption Support for TCP April 1995 [MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [PGP] P. Zimmermann, "Pretty Good Privacy", ConneXions Vol. 8, No 12, December 1994. [RFC793] J. Postel, "Transmission Control Protocol", RFC 793, Sep- tember 1981. [RFC1704] N. Haller, R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. Annex. Events processing. The QOS are referred as 'TWOWAYS', 'ONEWAY', 'TGUP' as pre- viously stated. following annex describes the action to be done and the resulting state of the TCP connection. The TCP state is CLOSED. The client open the connection. If its QOS is: NONE: Send a normal TCP packet. TWOWAYS: Is the peer's public key available? NO: Return with an error. YES: Send a SYN packet with a TCPOPT_CRYPT option and the crypted IDEA key. TGUP: ONEWAY: Is the peer's public key available? NO: Send a SYN packet with a TCPOPT_CRYPT option and a null size IDEA key. YES:Send a SYN packet with a TCPOPT_CRYPT option and the crypted IDEA key. The TCP state is LISTEN. The server receives a TCP packet with a TCPOPT_CRYPT option. If its QOS is: NONE: If the server support the encryption then change its QOS to TGUP and process as described. If not, ignore the option. TGUP: ONEWAY: Is the IDEA key lenght null? NO:Store the key as the send key. YES:Use our receive key for sending if available. TWOWAYS: Is the IDEA key lenght null? NO:Store the key as the send key. YES:Drop the connection. (Send a RST packet) The server also generate its own 'receive key' with the same algorithm than the client in CLOSED state. The TCP state is SYN_SENT. The client receives a TCP packet with a TCPOPT_CRYPT option. If its QOS is: NONE: If the client support the encryption then change its QOS to TGUP and process as described. If not, ignore the option. TGUP: ONEWAY: Is the IDEA key lenght null? NO:Store the key as the send key. YES:Is our 'receive key' set? NO:Drop the connection. YES:Use it for sending. TWOWAYS: Is the IDEA key lenght null? NO: Store the key as the send key. YES:Drop the connection. The TCP state is SYN_RECEIVED. The client receives a TCP packet with a TCPOPT_CRYPT option. If its QOS is: NONE: If the client support the encryption then change its QOS to TGUP and process as described. If not, ignore the option. TGUP: ONEWAY: Is the IDEA key lenght null? NO:Store the key as the send key. YES:Is our 'receive key' set? NO:Drop the connection. YES: Use it for sending. TWOWAYS: Is the IDEA key lenght null? NO:Store the key as the send key. YES: Drop the connection. Return to Merit Home Page. Return to Routing Arbiter Home Page. Maintainer: webmaster@www.ra.net; Last Updated: 18 May 1995