[20271] in Kerberos_V5_Development
Re: Adding support for optimistic preauth to kinit
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Apr 6 01:12:35 2021
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <569c59b1-312d-edaa-a94a-3f95b53650c4@mit.edu>
Date: Tue, 6 Apr 2021 01:12:23 -0400
MIME-Version: 1.0
In-Reply-To: <202104050340.1353e55Q024670@hedwig.cmf.nrl.navy.mil>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 4/4/21 11:43 PM, Ken Hornstein wrote:
> Really, the REAL goal is to force a particular preauth mechanism. We have
> patches to kinit that make it so when kinit is called as "pkinit", it
> will try PKINIT by default. The way this is done is by setting the
> optimistic preauth list.
I'm curious what this was needed for. Our initial ticket code is pretty
aggressive about trying PKINIT if the KDC offers it. Not only do KDCs
tend to offer PKINIT first when they're configured for it, but even if
they don't, the client code sorts the PKINIT types to the front of the
list (overridable with [libdefaults] preferred_preauth_types). So,
putting PKINIT in the optimistic preauth list wouldn't seem to change
the behavior of kinit except to save a round trip.
>> A path of lower resistance is to add an option to force a particular
>> preauth mech (single choice, hard-failing if it isn't available or
>> doesn't work). clpreauth modules already declare names like "pkinit"
>> and "sam2" which could be matched against.
>
> Honestly, I'd be fine with this (although it does occur to me that you
> might want to specify more than one preauth to use)
What use cases do you have in mind for specifying more than one?
I'd be willing to consider a patch in this direction, since my other
ideas aren't well-formed enough to pursue.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
