GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Tom Yu]

Russ Allbery <rra at stanford.edu> writes:

> Adam Megacz <megacz at cs.berkeley.edu> writes:
>> Russ Allbery <rra at 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.