[32441] in Kerberos
Re: GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH
daemon@ATHENA.MIT.EDU (Tom Yu)
Tue Jun 8 20:13:33 2010
To: Russ Allbery <rra@stanford.edu>
From: Tom Yu <tlyu@mit.edu>
Date: Tue, 08 Jun 2010 20:13:25 -0400
In-Reply-To: <874ohdkzgb.fsf@windlord.stanford.edu> (Russ Allbery's message of
"Tue, 08 Jun 2010 14:05:08 -0700")
Message-ID: <ldvvd9t6p22.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Russ Allbery <rra@stanford.edu> writes:
> Adam Megacz <megacz@cs.berkeley.edu> writes:
>> Russ Allbery <rra@stanford.edu> writes:
>
>>> Check the host/* principal on the system to which you were
>>> authenticating. I bet that the REQUIRES_PRE_AUTH flag was set for it,
>>> which means that only tickets that are pre-authenticated can
>>> authenticate to that service principal.
>
>> Indeed, that was it! Russ saves the day again.
>
> The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
> one authenticates rather than principals one authenticates as always
> strikes me as surprising, unexpected, and unintuitive.
We are open to suggestions about how to remedy this behavior. I think
it stems from the KDB flag REQUIRES_PRE_AUTH being overloaded with two
mostly unrelated meanings: (1) require preauthentication when the
specified client obtains initial tickets; (2) require that any
client's service ticket have the "preauthenticated" flag set when
presented to a specified service.
How many people have a security policy that requires behavior (2)
above? If so, is it necessary to conflate that behavior with behavior
(1)?
>> Curious: I assume that the failure mode here is some variation on the
>> sshd machine asking the KDC for a delegation and the KDC refusing.
>
> I believe it fails even if you're not doing delegation. I believe the KDC
> refuses to issue you a service ticket for a principal with
> REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated. But
> I don't remember the details of the research that I did when I ran into
> this. (We just cleared that flag from principals like host/* principals
> and moved on with our lives; given that they're randomly generated keys,
> hopefully brute force attacks are difficult anyway.)
That matches my recollection, but I haven't examined the relevant code
recently.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
