Newsgroups: sci.crypt
Path: msuinfo!uchinews!linac!att!walter!qualcom.qualcomm.com!qualcom.qualcomm.com!karn
From: karn@qualcom.qualcomm.com (Phil Karn)
Subject: Re: secure telnetd password encryption & authentication techniques
Message-ID: <1992Feb20.005723.19080@qualcomm.com>
Sender: news@qualcomm.com
Nntp-Posting-Host: qualcom.qualcomm.com
Reply-To: karn@chicago.qualcomm.com
Organization: Qualcomm, Inc
References: <1992Feb13.190458.20395@qualcomm.com> <h9fb760@fido.asd.sgi.com>
Date: Thu, 20 Feb 1992 00:57:23 GMT
Lines: 104

In article <h9fb760@fido.asd.sgi.com>, nelson@bolyard.wpd.sgi.com writes:
|> There exist certain large communities of computer users within the US
|> Government that have established their own "standard" for using Kerberos
|> for TELNET, FTP, and other older TCP-based protocols.  Their approach is
|> to use a Kerberos authentication exchange before allowing the older
|> protocol to run, so that one the older protocol (say FTP) begins to run,
|> it need not operate differently than before.  This "wrap authentication
|> around the old protocol" approach has the advantage that is is quite easy
|> to do for most TCP (or COTP) based application protocols, and it is
|> consistently done accross all cases.

My approach of putting the authentication and/or encryption *below*
TCP (which is of course below the application) is even more
transparent to the applications -- they don't really have to know
anything about it. But when you add authentication or encryption to
the applications, you can't but help make it harder to interoperate
with exisiting implementations, because you *are* after all changing
the application's protocol. And you have to do the job anew for each
new application.

|> There are several problems with this approach of using IP options for 
|> authentication, both technical and business problems.  For the past two
|> years, I have participated in the TSIG/IETF Commercial IP Security Option
|> (CIPSO) working group, and have learned first hand the problems of adding
|> an IP option.

[good arguments against doing it as an IP option deleted...]

|> So, I'm convinced that authentication and confidentiality need to be done
|> at a higher layer (in the ARM) than IP.  

Okay, you've convinced me not to do it as an IP option. So instead
I'll insert two new protocols to ride atop IP but under TCP and UDP,
one for authentication and one for encryption. Or better yet, I'll
create one common protocol to do both encryption and/or
authentication. This actually would be better architected than the IP
option because the IP routers don't really need to know that a
datagram is encrypted or authenticated -- it's an end to end issue, so
it should go in an end-to-end layer.

|> You could invent new transport protocols (using a different number than 6
|> for TCP or 17 for UDP) that are encrypted-TCP and encrypted UDP, but it
|> would be easier to use TCP-header options, or to add a new layer of
|> protocol on top of TCP, but below sockets.  This is exactly what the TSIG
|> Trusted Sessions Working Group (TSWG) is doing at the moment.

The authentication/encryption "protocol" could include the original IP
protocol field so you could just run standard TCP and UDP (or whatever
else you want) on top of it, without change. Why invent new transport
protocols if you don't have to?

|> Having the data confidentiality (encryption) ride on top of the transport
|> protocol has the advantage that you can use the more-secure chaining
|> encryption methods (e.g. Cipher Feedback Mode, or Output Feedback Mode) 
|> on the byte stream, and not have to worry that fragmentation/reassembly or
|> datagram misordering will mess up your ability to correctly decrypt the
|> data.

Perhaps, but putting encryption above TCP means that an intruder can
still play games with your TCP. He can maliciously reset connections,
modify (ciphertext) data and recompute valid TCP checksums so that the
receiving TCP doesn't know the difference, all in the hope of
hopelessly confusing the victim's application when it decrypts
incoming data into gibberish. (Just consider doing this to somebody's
FTP data connection.) Putting the authentication and encryption
*below* TCP effectively blocks all but replay and complete
denial-of-service attacks. The latter is effectively impossible to
stop in an open network, but the former is made much more difficult by
the fact that TCP is already designed to be resistant against
long-delayed duplicates.  And you can still use cipher block chaining
within each encrypted datagram, and because of the changing sequence
numbers in the TCP headers you will not have the problems with
repetitive ciphertext blocks that you might have if you were just
ciphering raw text.

One of my goals for an authentication/encryption "protocol" is to
allow a handy but safe means to penetrate the brain-damaged "router
firewalls" that now surround so many company networks. You could do
this by setting up a "security gateway", with connectivity to both the
internal and external nets, that accepts datagrams from the outside
that use the security protocol. Authorized external hosts (i.e., those
having the necessary crypto keys) could encapsulate IP datagrams bound
for the internal network inside the security protocol and address them
(in an outer IP header) to the security gateway.  The security
gateway, after authenticating and/or decrypting each datagram, would
extract the original IP datagram from inside the packet and place it
on the internal network.  Return traffic from the internal network
could be sent directly to the external network, as now allowed by most
"diode" routers. Or, if encryption and/or authentication is desired in
both directions, it could be routed back through the security gateway
for encapsulation and encryption before transmission on the external
net.

I see MANY advantages to this approach that make it well worth the
effort.  First, you can provide to any authorized external host
secure, transparent IP-level connectivity to all of the hosts on your
network; no need to require your external users to put up with the
hassle of tandem telnet or staged FTP sessions through "firewall"
systems. Second, it is actually more secure, since you can encrypt and
authenticate each and every IP datagram if you like. And third, you can
do it WITHOUT having to modify all of your internal hosts to support
secure versions of each of their applications.

Phil
