krb5_rd_cred checks IP address.

[Steven Michaud]

Why not figure out a way to leave the address-checking decision up to
the application server?  (I.e. why not let whoever runs the
application server use a command-line parameter to determine whether
or not address-checking will be done?)

GSSAPI application servers use gss_accept_sec_context().  Currently
(release 1.2.3) krb5_rd_cred() doesn't do any address checking unless
at least one of the following members of its second parameter
(krb5_auth_context auth_context) is non-null --
auth_context->local_addr or auth_context->remote_addr.  When
krb5_rd_cred() is called from gss_accept_sec_context(),
auth_context->local_addr is always null (as you'd expect).  (It's set
by the call to krb5_auth_con_setaddrs() just beforehand.)  But when
gss_accept_sec_context() has been called with its input_chan_bindings
parameter set to GSS_C_NO_CHANNEL_BINDINGS, auth_context->remote_addr
is also null.  (Otherwise it gets set to the address specified in
input_chan_bindings.)

If this is OK for GSSAPI application servers, why not also for ssh-krb5?

Of course GSSAPI application servers have _other_ problems with NAT --
they still fail if the _client_ sends any channel bindings (the
failure takes place at line 423 -- the call to
kg_checksum_channel_bindings() -- accept_sec_context.c).  But that's
another story :-)

By the way, for those who might be interested, I've ported my NAT
fixes from release 1.2.2 to 1.2.3.  I've tested them for about a week
and they seem to work fine.  When I get a chance I'll post them here.

On Thu, 7 Feb 2002, Sam Hartman wrote:

> 
> 
> amu recently filed a Debian bug against my ssh-krb5 package
> complaining that when he forwarded addressless tickets from behind a
> NAT using ssh protocol version 1 to a new server, it didn't work.  It
> turns out all of those qualifiers are necessary to reproduce the bug;
> change one and it works fine.  Well, OK, if you get addressful tickets
> behind a NAT, it fails much earlier
> 
> 
> Here's the problem.  Our implementation of krb5_rd_cread checks the
> source address to make sure it matches the source address in the
> KRB-CRED structure.  It turns out it only does this if the krb-cred
> structure is encrypted.  It turns out that you'll only encrypt the
> structure under the ssh v1 forwarding mechanism when a new client
> talks to a new server.
> 
> I'm not really sure what good this check does other than to screw over
> NAT users.  Even if we pretend that we actually still care about IP
> address authentication what is the harm of accepting tickets from
> someone provided that they work?
> 
> I'm really not sure how to go about fixing this problem.  I could see
> solving in several ways and am not sure which one the community
> prefers.  Do we remove the check on the source address?  Do we do
> something special if you are forwarding addressless tickets?  
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
>