Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 21 Apr 2000 02:17:04 -0700 (PDT)

--- Jeffrey Altman <[email-masked]> 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 * [email-masked]
> 
> 
> 
regards,
suresh

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

---

From: Greg Hudson <[email-masked]>
Date: Fri, 21 Apr 2000 13:55:18 -0400

I'd like to make some clarifications about Kerberos and NAT.

> Are you saying that IP address of the senders is always embedded in

In Kerberos 4, when the KDC receives a ticket request, it includes the
source IP address in the returned ticket.  This works fine if the KDC
is across a NAT gateway, as long as all of the Kerberos services are
also across a NAT gateway.

In Kerberos 5, the client specifies a list of IP addresses which the
ticket should be valid for, or it can ask for a ticket valid for all
IP addresses.  By asking for an all-IP-addresses ticket or a ticket
containing the NAT gateway address, you can get krb5 to work with a
NAT gateway, although it isn't very transparent (it requires the
clients to behave differently than they otherwise would).  The MIT
krb5 1.0 implementation didn't have any configurability for what IP
addresses the client asked for (it always asked for the set of its
interface addresses) and did not interact well with NAT.  The MIT krb5
1.1 implementation allows you to put "noaddresses" somewhere in
krb5.conf to request all-IP-addresses-valid tickets.

Not all Kerberos 4 or 5 services actually check source IP addresses.
(I don't have a list of common Kerberos services which do or do not
check source IP addresses, unfortunately.  AFS is a good example of a
Kerberos 4 service which does not.)  Services which don't check are
obviously not picky about NAT gateways.

There are, of course, a substantial number of people who believe that
Kerberos source IP address checking is not worth the trouble, since it
is not a central part of the Kerberos security model.  (Basically, it
means if someone steals Kerberos tickets, they can't use them from a
different IP address unless they can forge the source IP address or
use services which don't check.)

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Apr 2000 17:38:54 -0400

> also across a NAT gateway.

doesn't this require the NAT to use the same inside<->outside address
binding for the connection between the client and the KDC as for
the connection between the client and the application server?
e.g. it seems like the NAT could easily change address bindings 
during the lifetime of a ticket.

Keith

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 21 Apr 2000 18:15:22 -0400

> during the lifetime of a ticket.

Correct.  I think Greg was thinking only of NATs which share a single
global address among multiple clients on a private network...

				- Bill

---

From: Greg Hudson <[email-masked]>
Date: Fri, 21 Apr 2000 18:25:24 -0400

> doesn't this require the NAT to use the same inside<->outside
> address binding for the connection between the client and the KDC as
> for the connection between the client and the application server?

True.  However, the same problem applies without NAT if the client
changes address bindings, so I wouldn't say this is really a
NAT-related problem.

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Apr 2000 18:50:33 -0400

> changes address bindings, 

granted, but how often do clients change address bindings in practice?

> so I wouldn't say this is really a NAT-related problem.

of course it's a NAT-related problem, in the sense that if you
have a NAT box and want to use Kerberos you are highly likely
to observe the problem.

for almost every kind of harm that NATs do to applications you can 
find some other means of causing the same problem.  but just because 
the problem can be caused by other things doesn't mean it's not 
related to NATs. 

Keith

---

From: "Paul B. Hill" <[email-masked]>
Date: Fri, 21 Apr 2000 20:27:35 -0400

>during the lifetime of a ticket.

Yup, so far I have always been able to work around this by opening up an 
SSL IMAP connection to remote server to stablize the address while I need 
to do other work. Oh the fun games we encounter when mixing security and 
NATs :)

Paul