gssftpd and gss_acquire_cred

ghudson@MIT.EDU ghudson at MIT.EDU
Mon Nov 16 16:48:35 EST 2009

gssftpd (and maybe also telnetd) calls gss_acquire_cred to get a
credential to pass to gss_accept_sec_context.  It uses the local
hostname as determined by gethostbyname on the result of gethostname,
and as a consequence won't work for any hostnames other than what it
sees as canonical, even if it has keytab keys for other names.

My understanding is that stock OpenSSH sshd does the same thing,
although if you have Simon's gss-keyex patch you can affect that
behavior by turning off GSSAPIStrictAcceptorCheck (default is to the
old behavior).

I've seen multiple claims that server apps should generally not use
acquire_cred and should just pass GSS_C_NO_CREDENTIAL to
accept_sec_context.  Correspondingly, I've heard claims that the
GSSAPIStrictAcceptorCheck variable in Simon's patch is needless
conservatism and that there's no reason anyone would want the default
setting (on).

My one concern is that without acquiring a credential, a custom-coded
client could use, say, an HTTP/hostname ticket to authenticate to the
ftpd service, if both keys live in the same keytab.  In some exotic
cases (such as proxied credentials, or forensic analysis of KDC logs)
that could be considered a security issue.  I'm willing to disregard
that issue as not compelling enough to outweight the usability issues
associated with hosts with multiple A records, but it seems worth at
least thinking about.

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.

More information about the krbdev mailing list