GSS_C_NO_NAME for desired_name?

[Brian Candler]

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?

Regards,

Brian.