Re: Adding support for optimistic preauth to kinit
Greg Hudson <[email protected]> Tue, 6 Apr 2021 01:12:23 -0400
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev