gssftpd and gss_acquire_cred

[Tom Yu]

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>>Opinions?  Also, telnetd does something similar in telnetd/spx.c
>>(although it uses only gethostname to determine the hostname to use,
>>no gethostbyname call), but I don't know whether that code is actually
>>used; information on that would be appreciated.
>
> For telnetd the code you care about is in libtelnet/kerberos5.c; the
> code in spx.c is not used AFAIK.
>
> ftpd is the only application server shipped with MIT Kerberos that
> does this canonical name check; it's been a giant pain in the ass
> for nearly forever.  We have a local patch which does a getsockname()
> on the connection socket, but I've come to the conclusion that it's more
> trouble than it's worth and GSS_C_NO_CREDENTIAL is easier.  Yes, there's
> a slim possibility of a security vulnerability in some weird corner cases,
> but IMHO those potential problems are not worth the impact to usability.
>
> And Greg ... if you're really up for fixing long-standing multihomed
> bugs with MIT Kerberos, I don't suppose you're willing to look at
> password changing, are you?  That's been broken for nearly forever
> as well (well, I suppose it's more hits you if you're behind a NAT);
> I can supply gory details if you're interested.

As I recall, the kpasswd situation runs up against the hard wall of
KRB_PRIV requiring addresses.  There are (in RFC 4120) "directional"
addresses but there is no obvious (at least to me) way to negotiate
them.  If you have suggestions of how to backward-compatibly negotiate
the use of directional addresses, I'd love to hear about it.
Convincing arguments about the safety of forgoing the address checks
in the kpasswd case are also welcome.