[33016] in Kerberos
Re: GSS_C_NO_NAME for desired_name?
daemon@ATHENA.MIT.EDU (Simon Wilkinson)
Sat Jan 1 14:15:27 2011
Message-Id: <CA2BD604-6EF5-468B-B7AC-B8DCB270744B@sxw.org.uk>
From: Simon Wilkinson <simon@sxw.org.uk>
To: Brian Candler <B.Candler@pobox.com>
In-Reply-To: <20110101164855.GA4374@talktalkplc.com>
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 1 Jan 2011 19:15:19 +0000
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 1 Jan 2011, at 16:48, Brian Candler wrote:
>
> 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.
You're not necessarily only concerned with local attackers here.
Encryption key strength can also come into play. For example, say you
have deployed Kerberised NFS, and yet many of your clients can only
use single DES encryption types. But, as corporate policy, you have
moved to AES based encryption types for login services. If you have
both keys in the same keytab (and both NFS and ssh are very keen on /
etc/krb5.keytab), and your sshd accepts any principal in that keytab,
then an attacker only has to break the NFS DES key to compromise your
ssh service.
The point here is that it's hard to give hard and fast answers to some
of these questions. What's fine for one site's security policy may be
radically different for a different site - it all depends on your
analysis of your local risks.
Cheers,
Simon.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
