host name resolution, again (krb5-1.3-alpha1 is available)

[Donn Cave]

On Fri, 14 Mar 2003, Sam Hartman wrote:
| I would certainly consider looking at patches to applications that did
| a gethostbyname() or getaddrinfo() on the user-supplied name and took
| both the hostname and address from that reply.  The hostname should be
| passed to GSSAPI and the address used for the connect.
|
| I would object to patches that add additional dependences on reverse
| resolution especially if the add dependence on reverse resolution
| outside krb5_sname_to_princ for GSSAPI applications.
|
| In general, doing this securely is hard and requires KDC support we do
| not currently have.

That might be better than nothing.

gethostbyname() won't help, as in this case we're talking about a
real "A" name, just not a canonical one, so you get the same host
name out of gethostbyname() that you put in.  But you can get a
canonical name out of getaddrinfo if you ask for it, at least if
the platform has a working getaddrinfo().

Or it is of course something I can fix on my own in our copy of the
source, as I have been doing for lo these many years for ftp, and
we can distribute the patch around to other sites in our realm.
Unfixed, the problem basically cripples any Kerberos ftp or telnet
client for use here, so it actually has been much more important
to get other implementations fixed, like Fetch for example whose
author has been very responsive.

If this really is a serious security issue that can't be resolved
somehow, then I guess we may be in a position where it isn't worth
continuing to support Kerberos client applications at all.  We'd
be left with the occasional GSSAPI IMAP client (because our mail
hosts aren't clustered), and it seems unlikely that on its own
would warrant Kerberos support for desktop platforms.

That will affect a fairly small percentage of our users, mostly
MacIntosh users, but it will take a while to effect a transition
like this, so it would be helpful to get some more detailed
information about the problems we're exposed to in the meantime.
We're not the only site with addresses like this, either.

Thanks,
	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu