[33006] in Kerberos
Re: GSS_C_NO_NAME for desired_name?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Dec 31 12:34:27 2010
From: Greg Hudson <ghudson@mit.edu>
To: Brian Candler <B.Candler@pobox.com>
In-Reply-To: <20101231113239.GA9095@talktalkplc.com>
Date: Fri, 31 Dec 2010 12:34:13 -0500
Message-ID: <1293816853.2456.238.camel@ray>
Mime-Version: 1.0
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 Fri, 2010-12-31 at 06:32 -0500, Brian Candler wrote:
> I'd like to propose this upstream, but first would like some feedback as to
> whether this is likely to be a safe change to make, remembering that some
> people may be using older versions of MIT, or different Kerberos libraries,
> underneath GSSAPI.
It's quite interoperable.
The one potential concern is that by allowing the initiator to use any
key in the keytab, you could potentially allow a client to authenticate
to, say, a host service using an HTTPD service ticket, if both keys are
in the host keytab. That gives your httpd a way to get root access,
potentially. Most people in the Kerberos community do not consider this
a compelling concern relative to the problems introduced by importing
servicename@gethostname().
Something I'd like to do is make it so that if you import a host-based
service name like "host"--currently interpreted as
host@gethostname()--then the acceptor would allow any host key in the
keytab, but not keys for other services. But even if I were to
implement that today (and it's not trivial to do), it wouldn't be
behavior an app could rely on for years, or ever if other
implementations didn't follow suit.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
