[33010] in Kerberos
Re: GSS_C_NO_NAME for desired_name?
daemon@ATHENA.MIT.EDU (Brian Candler)
Sat Jan 1 09:31:47 2011
Date: Sat, 1 Jan 2011 14:31:29 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20110101143129.GA4124@talktalkplc.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1293816853.2456.238.camel@ray>
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, Dec 31, 2010 at 12:34:13PM -0500, Greg Hudson wrote:
> 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.
But if you were able to get a ticket for HTTP/foo, wouldn't the KDC also
give you a ticket for host/foo ?
My understanding was that Kerberos was about authentication rather than
authorization, and the KDC will happily give you a ticket for anyone that
you want to prove your identity to. Are some people putting controls on the
issuance of tickets as a means of access control?
Regards,
Brian.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
