gssftpd and gss_acquire_cred

[Love Hörnquist Åstrand]

If you care about the name, check service afterward.

The server probably doesn't know all names the kdc have given it though aliases.

gethostname() doesn't return a useful name that use useful in kerberos sense.

Love

16 nov 2009 kl. 13:48 skrev ghudson at MIT.EDU:

> 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.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev