using Kerberos V5 with network address translation firewall?
Jianlin Chang
on subject 'Patch for making Kerberos work through Firewalls and NATs', it
seems to indicate that there are still a number of problems, e.g, ticket
forwarding. Can these problems be easily resolved? I don't seem to see a
solution from the those emails. Thanks.
>-----Original Message-----
>From: Turbo Fredriksson [mailto:tu...@bayour.com]
>Sent: Wednesday, June 20, 2001 12:55 PM
>To: Jianlin Chang
>Cc: kerb...@MIT.EDU
>Subject: Re: using Kerberos V5 with network address translation
>firewall?
>
>
>>>>>> "Jianlin" == Jianlin Chang <ch...@platform.com> writes:
>
> Jianlin> Does Kerberos V5 work with network address translation
> Jianlin> firewall?
>
>As long as you don't block port 88, yes...
>
> Jianlin> I am interested in the following situation,
> Jianlin> the client and server are behind two separate firewalls.
> Jianlin> The KDC may or may not be behind a third firewall.
>
>If the KDC have a internal, invisible IP address, no.
>
> Jianlin> I guess that client can still obtain tickets properly,
> Jianlin> even if the IP address in the ticket is that of the
> Jianlin> proxy.
>
>The clients will have to be able to reach the KDC.
>
> Jianlin> But what happen to the server? When you try to 'kadmin
> Jianlin> ktadd' on the server to add the server's key to keytab
> Jianlin> file, will it work properly?
>
>As long as you don't block port 750, yes.
>
> Jianlin> Now that client has a ticket, and server knows the key,
> Jianlin> will the client be able to connect to the server
> Jianlin> properly?
>
>The 'client communication' is done on port 88, server communication
>(ie kadmin etc) on port 750.
>
> Jianlin> BTW, during the process of 'kadmin ktadd', when the
> Jianlin> server host contacts KDC, is the key transmitted
> Jianlin> encrypted? If yes, how?
>
>This is shaky ground to me, but I will hazzard a (qualified) guess
>from what i've learnt reading the kerberos RFC's etc.
>_ALL_ communication to/from the KDC are encrypted... Exactly HOW
>this is done can be found (?) on the URL (very technical):
>
>http://www.isi.edu/gost/publications/kerberos-neuman-tso.html
>
>
>--
> Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just
> ^^^^^ / /(_)_ __ _ ___ __ selective about who its friends are
> / / | | '_ \| | | \ \/ / Debian Certified Linux Developer
> _ /// / /__| | | | | |_| |> < Turbo Fredriksson tu...@tripnet.se
> \\\/ \____/_|_| |_|\__,_/_/\_\ Stockholm/Sweden
>
>ammunition Cocaine Panama cryptographic 747 terrorist SDI smuggle FBI
>South Africa AK-47 critical tritium class struggle Delta Force
>[See http://www.aclu.org/echelonwatch/index.html for more about this]
>
Jeffrey Altman
Jianlin Chang <ch...@platform.com> wrote:
: Searching through the Kerberos mailing list archive, especially the thread
: on subject 'Patch for making Kerberos work through Firewalls and NATs', it
: seems to indicate that there are still a number of problems, e.g, ticket
: forwarding. Can these problems be easily resolved? I don't seem to see a
: solution from the those emails. Thanks.
The problem with forwarding of tickets is that when tickets are
forwarded they are sent to the host after calling
krb5_auth_con_genaddrs() with KRB5_AUTH_CONTEXT_GENERATE_LOCAL_FULL_ADDR
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.
If you can describe a good way to write the rule that says, replace
address FOO with address NAT we can certainly make the change in the code.
The problem in most cases is that there is no good way to know what
the NAT address is in the first place.
For C-Kermit / Kermit 95, when the NAT is a Linksys DSL / Cable Router
I have written the following script. But it doesn't help with forwarding.
# get-linksys-addr.ksc
# This script can be used with a Linksys Ethernet Cable/DSL Router
# to retrieve the IP address for use with Kerberos 5 authentication
# when Network Address Translation (NAT) is enabled.
#
# by Frank da Cruz and Jeffrey Altman
#
# Version 1.0
if < \v(version) 800200 {
end 99 This script requires C-Kermit or Kermit 95 version 800200 or higher
}
# define some default
local firewall fwuser fwpwd tempfile \%x addr
define firewall 192.168.1.1 ; default value
define fwuser ; default value
define fwpwd admin ; default value
define tempfile \v(tempdir)linksys.htm
# Perform HTTP GET and place the Status HTML page into the tempfile
http open \m(firewall)
if failure end 1 Unable to connect to firewall
http /user:\m(fwuser) /password:\m(fwpwd) get /Status.htm \m(tempfile)
if failure end 2 Unable to access Status.htm: \v(http_code): \v(http_message)
http close
# Read the contents of the tempfile into the data variable
file open /binary /read \%x \m(tempfile)
if failure end 3 FOPEN \m(tempfile): \f_errmsg()
file read /size:\fsize(\m(tempfile)) \%x data
file close \%x
# Delete the tempfile
delete \m(tempfile)
# The IP Address of the Router is located in the HTML file
# within a block defined by tags: <!--WAN head--> and <!--WAN tail-->
# We extract the substr defined by the block
.\%x := \findex(<!--WAN head-->,\m(data))
if not \%x end 4 Header <!--WAN head--> not found
.\%y := \findex(<!--WAN tail-->,\m(data),\%x)
if not \%y end 5 Header <!--WAN tail--> not found
.data := \fsubstr(\m(data),\%x,\%y-\%x+15)
# The IP Address is located after the string "IP Address:".
# Find its location in the WAN block
.\%x := \findex(IP Address:,\m(data))
if not \%x end 6 IP Address tag not found
# Extract the IP Address
.addr := \fipaddress(\m(data),\%x)
if failure end 7 No ip address found
# Set the IP address of the Router to be used in Kerberos 5 tickets
set auth k5 addresses \m(addr)
# Done
end 0 Kerberos 5 address list set to: \m(addr)
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-...@kermit-project.org OpenSSL. SSH soon to follow.
Russ Allbery
> If you can describe a good way to write the rule that says, replace
> address FOO with address NAT we can certainly make the change in the
> code. The problem in most cases is that there is no good way to know
> what the NAT address is in the first place.
I think there used to be patches for this around somewhere for something
of the 1.0.x vintage, because I forward-ported them to 1.2 until I started
just using addressless tickets. That patch took the approach of requiring
one to configure the NAT IP address in krb5.conf, which would work in some
situations.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Jeffrey Altman
Russ Allbery <r...@stanford.edu> wrote:
The patch worked by adding the additional addresses into the TGT.
This allows service tickets acquired with the modified TGT to be
used for authentication. However, it does not work with forwarding
of tickets because it is not possible for the address binding that
is used to protect the forwarding of tickets to have more than one
address value. There is no mechanism to say that the current local
IP address/port should be replaced by the IP address/port used by
the NAT/Firewall when it makes its outgoing connection to the
eventual host. There just is no mechansism available for the
client app to probe the NAT/Firewall to find out what the value is.
SOCKS 4 has exactly the same problem. SOCKS 5 fixed it by having
the SOCKS gateway report the outgoing IP address/port info to the
SOCKS client. That way when the application inquires for the
local ip address/port used by the socket what is returned is not
the info for the local machine, but instead the info for the
socket created by the SOCKS gateway.
Michael Thomas
> 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.
--
Michael Thomas (mi...@mtcc.com http://www.mtcc.com/~mike/)
Multi-mode fiber with an optical splitter |
B G P sessions conFIGGED not to litter | My Fav'rite 'Net Things
Reverting from A T M back to I P | by kc claffy, CAIDA
These are a few of my fav'rite `Net things |
Donn Cave
Sounds to me like two ways to describe the same problem: "there is no
good way to know what the NAT address is" vs. "would work in some
situations."
If you're going to configure Kerberos for a several thousand people
whose ISPs are pushing NATs, and who have only a glimmer of a notion
what that means and will be using a variety of implementations, and
whose only recourse if it doesn't work is probably to have you come
over to their house, addressless tickets is the only option, right?
(i.e., "noaddresses = true" in "[lib-defaults]" in krb5.conf.)
I understand that has been working for most applications. The only
problem seems to be ftp (Fetch), where GSS channel bindings bring
the local address back to cause more trouble. Would someone mind
confirming that any GSS ftp client will necessarily have this problem,
and it isn't something the application could handle?
Thanks,
Donn Cave, do...@u.washington.edu
Jeffrey Altman
Donn Cave <do...@u.washington.edu> wrote:
: If you're going to configure Kerberos for a several thousand people
: whose ISPs are pushing NATs, and who have only a glimmer of a notion
: what that means and will be using a variety of implementations, and
: whose only recourse if it doesn't work is probably to have you come
: over to their house, addressless tickets is the only option, right?
:
: (i.e., "noaddresses = true" in "[lib-defaults]" in krb5.conf.)
:
: I understand that has been working for most applications. The only
: problem seems to be ftp (Fetch), where GSS channel bindings bring
: the local address back to cause more trouble. Would someone mind
: confirming that any GSS ftp client will necessarily have this problem,
: and it isn't something the application could handle?
FTP GSSAPI-KRB5 does not require Channel Bindings. Any server
that requires Channel Bindings is out of spec. Versions of MIT
Kerberos FTPd had this bug. The current release does not.
Ken Hornstein
>problem seems to be ftp (Fetch), where GSS channel bindings bring
>the local address back to cause more trouble. Would someone mind
>confirming that any GSS ftp client will necessarily have this problem,
>and it isn't something the application could handle?
As I understand it (when a similar issue came up before) .... channel
bindings are optional for ftp, and you can turn them off and still
be considered compliant with the spec. I think that will require mods
on both current clients and servers, though.
--Ken
Jeffrey Altman
Michael Thomas <mi...@mtcc.com> wrote:
: jal...@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.
Johan Danielsson
> If you can describe a good way to write the rule that says, replace
> address FOO with address NAT we can certainly make the change in the code.
> The problem in most cases is that there is no good way to know what
> the NAT address is in the first place.
I sometimes long for a "dear prof. kdc, please give me my correct
address, since I have no clue" option to the kdc, much like it worked
in v4.
/Johan
Jeffrey Altman
But that approach does not work either in multi-homed environments
because the IP address used to connect to the KDC is not necessary
the same one that is used to connect to the service. Nor is the KDC
and the service necessary on the in same sub-cloud. If they are on
different sides of the NAT/Firewall you still have the same problem.
So the often time suggested KDC solution is no better.
- Jeffrey Altman
Donn Cave
|: I understand that has been working for most applications. The only
|: problem seems to be ftp (Fetch), where GSS channel bindings bring
|: the local address back to cause more trouble. Would someone mind
|: confirming that any GSS ftp client will necessarily have this problem,
|: and it isn't something the application could handle?
|
| FTP GSSAPI-KRB5 does not require Channel Bindings. Any server
| that requires Channel Bindings is out of spec. Versions of MIT
| Kerberos FTPd had this bug. The current release does not.
Thanks, I checked it out and it works!
Of course, now either the client or the server has to back off on the
channel bindings. For my test, I still had to modify ftpd to specify
GSS_C_NO_CHANNEL_BINDINGS, but with the snapshot that's all I had to
do, no need to modify the gssapi support library.
In theory the client could have done that instead, but then it wouldn't
work with any currently released ftp, from 1.2 or earlier, so the only
way I could see that working would be as a client configuration option
in case you know you're behind a NAT where the channel bindings would
fail anyway.
Donn Cave, do...@u.washington.edu
Jeffrey Altman
Donn Cave <do...@u.washington.edu> wrote:
: | FTP GSSAPI-KRB5 does not require Channel Bindings. Any server
: | that requires Channel Bindings is out of spec. Versions of MIT
: | Kerberos FTPd had this bug. The current release does not.
:
: Thanks, I checked it out and it works!
:
: Of course, now either the client or the server has to back off on the
: channel bindings. For my test, I still had to modify ftpd to specify
: GSS_C_NO_CHANNEL_BINDINGS, but with the snapshot that's all I had to
: do, no need to modify the gssapi support library.
:
: In theory the client could have done that instead, but then it wouldn't
: work with any currently released ftp, from 1.2 or earlier, so the only
: way I could see that working would be as a client configuration option
: in case you know you're behind a NAT where the channel bindings would
: fail anyway.
:
: Donn Cave, do...@u.washington.edu
The 1.2.2 FTPD should not be requiring channel bindings. If the
channel bindings are provided by the client they are used. If the
bindings provided by the client are 0.0.0.0.0.0 then the GSSAPI
library will ignore them when authenticating the client. There
should be no need to use GSS_C_NO_CHANNEL_BINDINGS, because now
you are saying that the client must not send bindings either.
Donn Cave
|: | FTP GSSAPI-KRB5 does not require Channel Bindings. Any server
|: | that requires Channel Bindings is out of spec. Versions of MIT
|: | Kerberos FTPd had this bug. The current release does not.
|:
|: Thanks, I checked it out and it works!
|:
|: Of course, now either the client or the server has to back off on the
|: channel bindings. For my test, I still had to modify ftpd to specify
|: GSS_C_NO_CHANNEL_BINDINGS, but with the snapshot that's all I had to
|: do, no need to modify the gssapi support library.
|:
|: In theory the client could have done that instead, but then it wouldn't
|: work with any currently released ftp, from 1.2 or earlier, so the only
|: way I could see that working would be as a client configuration option
|: in case you know you're behind a NAT where the channel bindings would
|: fail anyway.
| The 1.2.2 FTPD should not be requiring channel bindings. If the
| channel bindings are provided by the client they are used. If the
| bindings provided by the client are 0.0.0.0.0.0 then the GSSAPI
| library will ignore them when authenticating the client. There
| should be no need to use GSS_C_NO_CHANNEL_BINDINGS, because now
| you are saying that the client must not send bindings either.
The MIT 1.2.2 ftpd does require channel bindings. I tried it with
the MIT client, and no channel bindings = bad channel bindings.
The way I see it, this comes down to krb5_gss_accept_sec_context()
in lib/gssapi/krb5/accept_sec_context.c, where in the recent snapshot
I find this comment:
If the server has specified input_chan_bindings equal to
GSS_C_NO_CHANNEL_BINDINGS then we skip the check. If
the server does provide channel bindings then we compute
a checksum and compare against those provided by the
client. If the check fails we test the clients checksum
to see whether the client specified GSS_C_NO_CHANNEL_BINDINGS.
If either test succeeds we continue without error.
and briefly the following code does
if not GSS_C_NO_CHANNEL_BINDINGS:
if channel bindings mismatch:
make GSS_C_NO_CHANNEL_BINDINGS checksum
now if channel bindings mismatch:
fail
The same function in 1.2.2 is different here, it just checks for
mismatch, so if one side uses GSS_C_NO_CHANNEL_BINDINGS, then the
other side must too.
The way this function works in recent krb5-current, the server
can specify GSS_C_NO_CHANNEL_BINDINGS and it will work for everyone.
Or the client can, but of course only if it's talking to this server.
Donn Cave, do...@u.washington.edu
Jeffrey Altman
Donn Cave <do...@u.washington.edu> wrote:
: The MIT 1.2.2 ftpd does require channel bindings. I tried it with
: the MIT client, and no channel bindings = bad channel bindings.
That is a shame. A patch for this was submitted to krb5-current.
Obviously, it was not pulled into the 1.2.2 distribution.
Johan Danielsson
It will work just as well if the kdc and the service is on different
sides of the nat, that is not at all.
In the other configurations it works much better.
> So the often time suggested KDC solution is no better.
Than what?
/Johan
Jeffrey Altman
Johan Danielsson <jo...@pdc.kth.se> wrote:
than adding addresses into the ticket from the client side.
NATs do not work well with embedded addresses.
Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available
Johan Danielsson
> than adding addresses into the ticket from the client side.
No, but the problem here is that you quite often can't know what
addresses to add. Something living on the outside of the NAT can.
/Johan