This draft is very incomplete and in my opinion not ready for prime
time. The working group has in the past requested lists of protocols
and applications which do not work with NATs. I have replied
discussing those items for which I am most familiar:
. Telnet (with AUTH, START_TLS, NEW-ENV, and XDISPLOC)
. FTP (with AUTH and PROT)
. RSH/RLOGIN/...
. Kerberos 4
. Kerberos 5
. X Windows
None of the information provided in a response to this request by me
is in this document. The protocols and applications listed above are
hardly unknown in the IETF community so it strikes me as intriguing
that these well known applications would be left out of a document
that is supposed to document how few problems are caused by NATs.
Telnet:
Transmits IP addresses from the client to the server for the purposes
of setting the DISPLAY variable. When set the DISPLAY variable is
used for subsequent connections from X clients on the host to an
X server on the workstation.
When AUTH is used with Kerberos 4 and Kerberos 5 there are issues
related to the IP addresses which are embedded into the Kerberos
tickets which specify the valid machines from which the tickets are
valid.
When START_TLS is used there may be client certificate verification
problems caused by the NAT depending on the information provided in
the certificate.
FTP:
As stated FTP, uses multiple sessions. But what it fails to state
is that if any form of PROT is used to secure the command channel
then it is impossible to implement an ALG to perform IP Address swaps.
When AUTH is used with Kerberos 4, Kerberos 5, and TLS the same
problems that occur with Telnet occur with FTP.
RSH/RLOGIN:
RSH uses multiple sessions to support separate streams for stdout and
stderr. The stderr socket is a connection from the server to the
client. And unlike FTP, there is no equivalent to PASV mode.
RLOGIN does not use multiple sessions.
But the Kerberos protoected versions of RSH and RLOGIN will not work
in a NAT environment due to the ticket problems and the use of
multiple sessions.
Kerberos 4:
Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be
written. The K4 ticket contains a single IP address describing the
interface used by the client to retrieve the ticket from the TGT from
the perspective of the KDC. If the KDC and all services are on the
far side of the NAT, the end user will not notice any problems. But
the ticket will be valid from any IP address inside the NAT (on the
private network.) Without a NAT, an attacker needs to be able to
spoof the source IP addresses of a connection that is being made in
order to use a stolen ticket on a different host. With a NAT, all
the attacker needs to do from the near side of the NAT is to simply
gain possession of a ticket.
Kerberos 5:
Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be
written. The K5 ticket contains a list of IP addresses from which
the ticket is to be considered valid. The list is generated by the
client machine, not the KDC. If the services being accessed with
Kerberos authentication are on the public side of the NAT, then
the Kerberos authentication will fail because the IP address used
by the NAT is not in the list of acceptable addresses.
There are two workarounds in Kerberos 5 both of which reduce the
security of the tickets. The first is to have the clients specify
the public IP address of the NAT in the ticket's IP list. But this
leads to the same security problem detailed for K4. Plus, how is
the client supposed to find out what the public IP Address of the NAT
is from the private side?
The second method is to remove all IP addresses from the K5 tickets
but this now makes theft of the ticket even worse since the tickets
can be used from anywhere. Not just from within the private network.
X Windows:
There are two problems in the X world. First, the X clients which are
in the public space need to make connections to the X Server which is
in the private space. The IP address to which the connections are to
be made is specified by the DISPLAY environment variable which is
set by the client in some way. The NAT would have to have an ALG
to replace the IP address and configure a port in the valid display
range (ports 6000 and higher) to act as a gateway.
But if the NAT listens for incoming connections then it may well
increase the security risk by providing access to the X server that
would not otherwise be available. Since the NATs tamper with the
IP addresses it will also not be possible for X Authorization methods
other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the
least secure of all the documented X Authorization methods.
-------
This small sampling of the types of information which are not provided
in this document is most likely just the tip of the iceberg. I
recommend that this document not be published in its current form due
to the overwhelming impression that is given to the reader that there
are no significant problems with NATs. Plus the document clearly
mentions areas where further research is required where the necessary
research is not difficult to perform.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
