--- Jeffrey Altman <jaltman(_at_)COLUMBIA(_dot_)EDU> wrote:
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:
Hmm.. I do not recall seeing your e-mail on this matter before.
I dont know how we could have lost it. Anyways, sorry about that.
<... stuff deleted>
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.
Agreed, if you use IP address of the X-server, instead of DNS name
(in the case of Basic-NAT en-route). In the case of NAPT enroute,
it is a non-issue, as you would have used just the IP address of
the NAPT device, right?
We covered this in section 3.1, but not in the context of telnet
(X-Windows client). Good point.
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.
Are you saying that IP address of the senders is always embedded in
the kerberos-4 tickets?
Section 6 attempts to state that any application that has private IP
address in the payload and its payload secured (and NAT is not party
to the security key) cannot traverse NAT device. We can certainly include
this application there.
Section 8.1 of RFC 2663 also talks about NAT limitations with regards
to applications with IP address content(especially, encrypted/authenticated)
When START_TLS is used there may be client certificate verification
problems caused by the NAT depending on the information provided in
the certificate.
Agreed. Same comment as before.
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.
Agreed. Will add text to clarify this.
When AUTH is used with Kerberos 4, Kerberos 5, and TLS the same
problems that occur with Telnet occur with FTP.
I guess, you are talking about sending IP address data encrypted
from a telnet station. Please elaborate, if I am missing something.
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.
Are you saying that there is a problem when a private host does
rsh into an external server? If so, can stderr be directed to the
client-host by name, as opposed to IP-address?
I donot know much about the inner-working of "rsh" to state whether it
can work with a NAPT device between client and server.
RLOGIN does not use multiple sessions.
What is the problem here?
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.
What is the issue with multiple sessions? Are you refering to one of the
sessions being redirected to the originator by address?
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.)
How so? Are you assuming that AUTH is not used?
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.
An attacker can be resourceful in many ways. An attacker does not need a
NAT to spoof an IP address. Private users of a NAT domain are assumed
to be within a trusting domain.
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.
OK.
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?
Yes. Sounds like a problem. RSIP may have a win here.
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.
Agreed. How do you expect the intruders will steal the tickets, without
being recipients of the ticket? Unless, you are assuming that the private
network is not trusted and that there are intruders 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.
Yes. I belive, we addressed this already under Telnet/DISPLAY.
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.
I dont understand how this increase the security risk.
Allowing access to X-servers is simply a matter of configuration. This
is not different from a firewall that configures the X-servers for external
access, for example.
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.
You may be right. I am not familiar with the 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.
I agree, the document in its current form is not ready for publication
as an RFC. It needs work. Thanks for your input. We will certainly
incorporate the comments in the next rev of the draft.
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 *
kermit-support(_at_)kermit-project(_dot_)org
regards,
suresh
__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com