GSS_C_NO_NAME for desired_name?

Brian Candler B.Candler at
Sat Jan 1 11:48:55 EST 2011

On Sat, Jan 01, 2011 at 02:54:20PM +0000, Simon Wilkinson wrote:
> The problem that Greg is pointing out is that this also works in reverse.
> If you know HTTP/foo's key material, then you can create tickets which
> allow you to authenticate to HTTP/foo as any user.  Typically this isn't
> an issue, because knowing the key material indicates that you have control
> of the service, and could already impersonate those users to it locally.
> However, with shared key material, this becomes more problematic. If
> HTTP/foo is used both by httpd, and by sshd, then having possession of the
> HTTP/foo key material allows you to impersonate any user to the sshd. 
> Whether this is, in fact, a privilege escalation depends on exactly how
> your machine is configured.

That's clear, thank you. The implication is that to avoid that problem it's
important that you have different keys and keep them in separate files:
HTTP/foo's key should only be readable to httpd, and host/foo's key only
readable to sshd.

But the original question was slightly different. In a situation where there
*are* multiple keys in the same file, then I see no particular reason why
sshd should only accept tickets for host/foo and httpd should only accept
tickets for HTTP/foo.

That is: if someone broken into httpd, and it was using a shared keytab
which also contained the sshd key, then they'd be able to go fetch (and
abuse) the sshd key.  And on the flip side, a user who has a legitimate
ticket for HTTP/foo would also be able to get a legitimate ticket for
host/foo, so there's no additional problem if sshd happens also to accept
the HTTP/foo ticket.

So if I understand it right, there isn't a problem with allowing a service
to decrypt a ticket using any key in the keytab.  The problem is putting
multiple service principals' keys in the same keytab in the first place.

Does that make sense?



More information about the Kerberos mailing list