GSS_C_NO_NAME for desired_name?

[Simon Wilkinson]

On 1 Jan 2011, at 14:31, Brian Candler wrote:

> 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 ?

Sure, if you know Alice's password, then the KDC will give you service tickets which allow you to identify yourself as Alice for any service. So, you can authenticate to HTTP/foo, or host/foo, or many others.

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.

S.