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