[33013] in Kerberos
Re: GSS_C_NO_NAME for desired_name?
daemon@ATHENA.MIT.EDU (Brian Candler)
Sat Jan 1 11:49:07 2011
Date: Sat, 1 Jan 2011 16:48:55 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Simon Wilkinson <simon@sxw.org.uk>
Message-ID: <20110101164855.GA4374@talktalkplc.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <C7363B10-6BE1-48AA-95E2-970203DE3B35@sxw.org.uk>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
