[14666] in Kerberos
Re: using Kerberos V5 with network address translation firewall?
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Thu Jul 12 14:06:03 2001
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Date: 12 Jul 2001 18:02:16 GMT
Message-ID: <9ikon8$raq$1@newsmaster.cc.columbia.edu>
To: kerberos@MIT.EDU
In article <v7itgy2phq.fsf@fasolt.mtcc.com>,
Michael Thomas <mike@mtcc.com> wrote:
: jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
: > Now this wraps the forwarded credentials in an auth context which
: > is bound to the local address/port and remote address/port. There is
: > no method that allows you to perform this binding and say
: >
: > hey wait a minute, whenever you see the local address 192.168.1.10
: > replace it with the address of the NAT (whatever that happens to be)
: >
: > This is done to protect the credentials. The host won't accept a
: > credential that is permitted for use on address A if it comes from
: > address B. The one exception to this rule is if you decide not to
: > embed ip addresses in the credentials at all. In that case, the
: > auth context is not bound to the endpoints of the socket pair.
:
: While not trying to defend NAT (heaven forfend),
: the use of IP addresses as a form of identity is
: an extremely suspect practice. Mobility, renumbering,
: and multihoming are all completely legitimate practices,
: and make the assumption of non-volatility of IP addresses
: completely wrong.
Let me restate what I wrote in the original response. The address
bindings are only used if in fact ip-addresses are embedded in the
TGT being forwarded. If the credential contains ip-addresses,
the address of the current session must be one of the ones in the
TGT. Otherwise, it will be rejected.
If you are using Kerberos with the no-address option, then there
are no bindings used to protect the forwarding of the TGT.
Kerberos tickets support multihoming. The issue with NATs is that
they are a poor substitute for engineering. Firewall traversal from
private to public address spaces SHOULD have been done via a real
protocol such as SOCKS. If that was the case, we would not be
having any of these application level problems.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
kermit-support@kermit-project.org OpenSSL. SSH soon to follow.
