[38786] in Kerberos
Re: Avoiding Pre-Auth/Auth Principal State Disclosure
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jul 1 15:34:39 2020
To: Eric Hattemer <ehatteme@usc.edu>, "kerberos@mit.edu" <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <c2bc7b92-4963-4a8d-e22c-f24de80ca84a@mit.edu>
Date: Wed, 1 Jul 2020 15:31:54 -0400
MIME-Version: 1.0
In-Reply-To: <e7075d39-df65-39ff-9389-432d38d0059f@usc.edu>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 7/1/20 1:53 AM, Eric Hattemer wrote:
> I know pre-auth is a special case where you'd need to provide a
> plausible challenge for non-existent accounts. But is there maybe a
> setting to treat unknown principals as if they had pre-auth disabled,
> request a password, and just send back invalid password / encryption
> failed no matter what?
We don't have a setting like that. The closest nod we have in the code
to this desire is a "vague errors" setting for the KDC, which can only
be turned on at compile time (or via ptrace, I guess) and causes the KDC
to yield generic errors instead of useful ones. But that setting still
allows an attacker to easily distinguish between "client principal
requires preauth" and "client principal not found".
Because the Kerberos principal namespace isn't formally divided between
users and services, any obscurity feature would probably have some edge
cases. For example, if we treated single-component principals as users,
anyone with a user/admin principal (or user/root, which has no status in
the code but is a common convention for elevated access) would probably
still be detectable by an attacker.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
