Updated NAT fixes

[Steven Michaud]

Here are updated versions of some of the patches I submitted to this
list in August, 2001.  They fix a bug in ftpd's support for
addressless tickets -- an ftp connection made over a NAT (with an
addressless ticket) no longer dies with a "failed accepting context"
error.  There used to be a NAT bug in telnetd -- connections made over
a NAT with an addressless ticket succeeded, but credential forwarding
would fail.  The removal of ip address checking from rd_cred in
release 1.2.5 beta 1 has eliminated that problem.  Hooray!

For some time, MIT Kerberos 5 has (rather grudgingly) included support
for addressless tickets.  A client behind a NAT can request an
addressless TGT.  Service tickets acquired with this TGT are also
addressless.  When they're used, in principle all
client-address-checking is turned off in the Kerberized application
server.  In exchange for a small erosion of security, a client gains
the ability to do Kerberos from behind a NAT.  The current MIT support
for addressless tickets works fine with some application servers --
notably UW's IMAP server.  But using an addressless ticket doesn't
turn off all client-address-checking in MIT's own ftpd.  (Nor did it
in telnetd.  But with the removal of all address checking from
rd_cred, the only remaining address checking takes place in rd_req
(actually in rd_req_dec), and that does work properly -- it only does
address checking if the service ticket has addresses in it.)

The ftpd patch I submitted in August gave ftpd two new parameters --
'-b' to turn off channel bindings (the GSSAPI version of address
checking), and '-B' (the default) to turn (or leave) it on.  This
version of ftpd either turned address checking off for all users
(whether or not they're using addressless tickets) or turned it on for
all users.  Turning address checking off for all users was (and is)
acceptable, because address checking doesn't actually increase your
security much (more on this topic below).

But now I've found a way to tie address checking to the presence or
absence of addresses in the service ticket contained in
gss_accept_context()'s input_token parameter.  This is better, but it
requires yet another change to gss_accept_context(), and possibly a
revision to the GSSAPI RFC.  (I add a definition of
GSS_C_CHANNEL_BINDINGS_FOLLOW_TICKET to gssapi.h, and use it as a
signal (in the application_data field of gss_accept_context()'s
input_chan_bindings parameter) that gss_accept_context() should ignore
channel bindings.)

I've attached all my patches to this message as zip files.
krb5-1.2.4-delegation-channelbinding-patch can be applied to either
releases 1.2.3 or 1.2.4.  krb5-1.2.5b1-channelbinding-patch is meant
for release 1.2.5 beta 1.  They're functionally equivalent, but
krb5-1.2.4-delegation-channelbinding-patch contains a couple of fixes
that exist in 1.2.5 beta 1 but weren't present in previous releases.

krb5-1.2.4-ftpd-channelbinding-followtkt-patch is the version of my
ftpd patch that follows the new design (it turns channel bindings on
or off according to the presence or absence of addresses in the
service ticket).  It can be applied to release 1.2.3, 1.2.4 or 1.2.5
beta 1.  On releases 1.2.3 and 1.2.4 it requires
krb5-1.2.4-delegation-channelbinding-patch.  On release 1.2.5 beta 1
it requires krb5-1.2.5b1-channelbinding-patch.

krb5-1.2.4-ftpd-channelbinding-params-patch is the version of my ftpd
patch that follows the old design (it uses command line parameters to
turn channel binding off or on).  It can be applied to release 1.2.3,
1.2.4 or 1.2.5 beta 1.  On releases 1.2.3 and 1.2.4 it requires
krb5-1.2.4-delegation-channelbinding-patch.  On release 1.2.5 beta 1
it doesn't require anything else (though the presence of
krb5-1.2.5b1-channelbinding-patch doesn't interfere with it).

I have detailed comments inside the patches themselves.  Please let me
know if you have any questions or comments.

Is there any chance that one of my ftpd fixes (or something like it)
will make it into release 1.2.5, or a release in the 1.2 series? :-)

Addendum

How much is your security eroded when all address checking is turned
off in the application server (whether because you've chosen to use
addressless tickets or for some other reason)?  As someone on this
list already pointed out, the server's replay cache should be able to
catch tickets that have been stolen in transit.  But someone could
still break into your computer (i.e. connect as root or as you) and
steal your ticket cache.  If that cache already contained service
tickets for the services whose client-address-checking had been
disabled, the hacker could connect as you to those services from any
other computer (not just your own), for the lifetime of the tickets.
(If your TGT was addressless, he could also get new service tickets
from any other computer, though with the same lifetime.)  However, if
the hacker could spoof your computer's ip address, he could connect as
you from other computers even to services whose
client-address-checking hadn't been disabled.  And he might be
perfectly happy to do his mischief from your computer (he might even
prefer it).  So the degree to which security is eroded depends on how
difficult it is for the hacker to spoof your computer's ip address and
how inconvenient it is for him to do further hacking from your
computer as opposed to some other computer.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5-1.2.4-delegation-channelbinding-patch.zip
Type: application/zip
Size: 2661 bytes
Desc: 
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20020410/40304006/attachment.zip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5-1.2.5b1-channelbinding-patch.zip
Type: application/zip
Size: 1322 bytes
Desc: 
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20020410/40304006/attachment-0001.zip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5-1.2.4-ftpd-channelbinding-followtkt-patch.zip
Type: application/zip
Size: 659 bytes
Desc: 
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20020410/40304006/attachment-0002.zip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5-1.2.4-ftpd-channelbinding-params-patch.zip
Type: application/zip
Size: 1073 bytes
Desc: 
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20020410/40304006/attachment-0003.zip