[39422] in Kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (James Ralston)
Mon Apr 29 19:18:43 2024
MIME-Version: 1.0
In-Reply-To: <aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
From: James Ralston <ralston@pobox.com>
Date: Mon, 29 Apr 2024 19:16:58 -0400
Message-ID: <CAEkxbZsfmBjohrjVNo9DvRUAB3yv1KZ3YjiBt2Dc4uNhf1U-oA@mail.gmail.com>
To: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Apr 16, 2024 at 1:46 PM Simo Sorce <simo@redhat.com> wrote:
> The correct action is for you to ask the Domain Administrators to
> mark the target hosts as ok for delegation, it is unclear why MIT
> Kerberos should make it easy to override Realm policies.
I think the core issue here is that RFC4120§2.8 was unclear in
defining the ok-as-delegate flag. Quoting RFC4120§2.8, emphasis mine:
* The ticket flags … *MAY* have the ok-as-delegate flag set
* A client *CAN* use the presence of this flag to *HELP* it decide
* It is acceptable to *IGNORE* the value of this flag
All of these statements are wishy-washy statements that provide no
concrete guidance for server/client implementers:
* Should server implementations set this flag by default unless
administrators specifically elect to disable it, or should server
implementations clear this flag by default unless administrators
specifically elect to enable it?
* Should client implementations honor this flag by default unless
administrators specifically elect to ignore it, or should client
implementations ignore this flag by default unless administrators
specifically elect to honor it?
* Given heterogeneous environments where there are likely to be
multiple independent client implementations, how should this feature
be deployed at a client and server level in order to minimize
interoperability issues?
In light of the failure of RFC4120§2.8 to answer any of these
difficult questions, I would argue that the MIT Kerberos behavior is
reasonable (arguably, the most reasonable): servers do not set the
flag by default, and clients do not honor the flag by default. This
leaves it up to individual sites to determine whether the additional
control this feature offers is desired, and if so, how to deploy it
without breaking things.
> Delegating a whole TGT is generally a bad idea, and often clients
> are misconfigured to broadly forward it everywhere. That is why
> Microsoft took back control in the hands of administrators. It is
> not a bad thing, and if your setup has been vetted such that TGT
> delegation is an acceptable risk, then it should be easy to get it
> fixed the proper way, by getting your domain admins to set the right
> flag on the permitted target hosts.
The issue is not that this feature exists; the issue is that until
recently, we simply *did not know* that this feature exists. And why
would we?
* Windows admins never had any reason to be aware of this feature,
because they use remote desktop to login to remote Windows hosts
from other Windows hosts.
* Linux admins never had any issues with delegating credentials from a
Linux host to another Linux host, because MIT Kerberos clients
ignore the flag by default.
* We assumed that the inability to delegate credentials from Windows
host to Linux hosts via PuTTY was a PuTTY implementation issue,
because that was the only instance where we saw delegation failing.
And PuTTY, at least with default logging, showed no warning/error
messages. Furthermore, because so few people were regularly logging
into Linux hosts from Windows hosts (people who did this often
simply requested a Linux workstation), it wasn’t worth the
time/effort to investigate further.
This state continued for the better part of a decade. It was only
when we began to officially support Mac desktops, and ssh clients on
those Macs also failed to delegate credentials (the same as PuTTY on
Windows), that we began to suspect there was a deeper issue at play.
> Note that if ticket delegation is needed solely to allow jumping
> from hosts to host, you should be able to achieve the same result
> via agent forwarding, it would be a safer option.
We use automounted NFS sec=krbp (AUTH_GSS security) home directories
everywhere, so users *must* possess a credential in order to access
their home directories. So even if we permitted publickey
authentication, it would not solve the issue of needing a credential
on the target host.
> But all that said I would like to note that it is certainly
> inappropriate to call people names before fully understanding the
> scope of a security measure, just because it is a little
> inconvenient.
Speaking as a Linux administrator in a heterogeneous environment where
our Linux hosts rely on Microsoft Active Directory, I assure you that
I have been calling Microsoft names for quite some time. ;-)
(Don’t even get me started about AD’s continued lack of support for
aes256-cts-hmac-sha384-192 or aes128-cts-hmac-sha256-128, when it’s
approaching 10 years since RFC8009 defined them, and Microsoft knows
that the legacy SHA-1 AES encryption types are increasingly giving
sites that are under the gun for FIPS compliance fits.)
I suspect that Microsoft was the main proponent of adding §2.8 to
RFC4120, and they cared little about clarifying behavior in the face
of heterogeneous KDC/client Kerberos implementations, because they
knew exactly how *they* intended to implement it for their KDC and
client.
And I stand by my criticism: silently denying the ability to delegate
credentials behind an obscure flag in the userAccountControl attribute
of the target host, in environments where it is *necessary* to possess
a valid credential on the target host, simply results in users
exposing their actual passwords to the target host (GSSAPI
authentication + kinit on the command line, or keyboard-interaction
authentication).
This is akin to password complexity / password change interval
restrictions that are so Draconian that users cannot remember their
passwords, and resort to writing their passwords on sticky notes that
they attach to their monitors.
> As for users that type their passwords onto random hosts, that is a
> user education problem in general
Not in this case, because these aren’t random hosts; they are hosts
that we (our site-wide IT team) build, deploy, and administer.
> but that can be addressed simply by forcing the use of 2FA
> authentication on the user's part
We already employ MFA for keyboard-interactive ssh logins, and for
console logins.
> preferably via a hardware token and pkinit
We have a subset of systems which must comply with DISA STIGs and for
which we must employ PKINIT using smart cards. For those systems, we
are grateful for all of the work you and others have put into sssd to
enable Linux hosts to perform PKINIT with AD as the KDC.
But for our systems that do not require PKINIT… due to our profoundly
negative experiences with hardware tokens, one of our requirements
when selecting an MFA implementation was software-based TOTP/HOTP with
fully-supported Android/iOS apps (a la Google Authenticator, although
we went with a different solution). Our solution doesn’t use PKINIT,
but instead performs an additional challenge once [non-PKINIT]
password authentication has already succeeded.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
