[39424] in Kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Tue Apr 30 12:50:05 2024
Message-Id: <202404301649.43UGnfNE028201@hedwig.cmf.nrl.navy.mil>
To: James Ralston <ralston@pobox.com>
cc: kerberos@mit.edu
In-Reply-To: <CAEkxbZupQObPrSC7PLvVV9+de8Pjj=d=dYRZWFvY3wMyUQPxMA@mail.gmail.com>
MIME-Version: 1.0
Date: Tue, 30 Apr 2024 12:49:41 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
>I think the core issue here is that RFC4120§2.8 was unclear in
>defining the ok-as-delegate flag.
I have to say that IMHO, the explanation in RFC 4120 is clear to me
and the current implementations within the MacOS X Kerberos code fall
squarely within the scope of the RFCs explanation. The "wishy-washy"
statements you describe are standard for introducing new protocol
extensions. You are, of course, free to express your opinions about the
implementation of these protocols extensions, but ... well, other than
the satisfaction of primal screaming into the void, I'm not sure how
helpful that will be.
>> Simo already explained the thinking there, but I think the thing
>> you're not considering is that not all services require delegated
>> credentials. Yes, in your environment (and ours) delegated
>> credentials for host principals is essential, but you don't normally
>> need that for other types of credentials. I haven't run into Simo's
>> experience of badly coded applications delegating credentials when
>> they shouldn't, but I could believe it happens.
>
>Our experience is similar: while I agree it could happen, we have not
>encountered it, so it is mystifying to us why Microsoft was so
>insistent upon implementing this feature.
In fairness ... in the normal Microsoft world, they do full credential
delegation very rarely, and they spent a lot of effort on constrained
delegation protocol extensions because the security issues associated
with delegating a TGT. Being able to centrally manage these things from
the KDC is not unreasonable! And yes, I do wonder what world people
live in when they suggest ssh agent forwarding as an alternative
to TGT delegation; to me ssh agent forwarding seems like a much worse
solution, but to each his or her own.
>It’s not a competency issue: our AD/Windows admins are highly
>competent (if I do say so myself), and we Linux admins enjoy good
>rapport with them. Rather, they expressed two concerns:
>[...]
I sympathize with these concerns, I do; it sounds like you're in a
tough spot.
>Upstream Heimdal has the enforce_ok_as_delegate krb5.conf
>configuration option, the same as the MIT Kerberos, and like MIT
>Kerberos, it defaults to false (only enforced when an application
>specifically requests enforcement) (1).
First off, I would advise you to NOT look at upstream Heimdal, because
that's not helpful because it's not actually the code in question.
Instead maybe look at the actual Heimdal source code used on MacOS X?
>But from testing, ssh on Macs won’t delegate the credential unless the
>service ticket of the target host has the ok-as-delegate flag. So
>either that’s not the default for Apple’s version of Heimdal, or
>something is overriding the default.
Here's the thing: I, personally, cannot reproduce this in our realm.
While we do provide our own ssh client, the stock MacOS X client still
delegates credentials just fine for us. Clearly it does not work
for you, so maybe investigating WHY it doesn't work for you would be
helpful. My guess is that there is some internal realm configuration
flag being set that tags your realm as a "windows" realm and triggers
the enforcement of the ok-as-delegate flag.
>> I will confess that we supply to our users Kerberos kits which are
>> all MIT sources, including OpenSSH, for this exact reason; there's
>> too much weird variance like this.
>
>In the past, we did the same thing, but we reverted to using the
>macOS-provided Kerberos implementation, because decisions Apple made
>in later macOS releases just made it too painful to replace it (or
>even provide an alternative implementation alongside the macOS
>implementation).
I do not agree with this statement. We still do this today, our
code works fine on everything up to and including Sonoma, and it
interoperates with the MacOS X Kerberos code fine. I am not sure what
decisions you are referring to.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
