Re: [krbdev.mit.edu #9046] requires_hwauth can cause a preauth loop with PKINIT
Sam Hartman <[email protected]> Fri, 21 Jan 2022 14:55:05 +0000
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <0100017e7d224024-75c7822d-2acd-46bc-b284-35086afc16d2-000000@email.amazonses.com> |
>>>>> "Ken" == Ken Hornstein via krbdev <[email protected]> writes: Ken> This touches a larger issue that I've run into, in that the Ken> client-side preauth loop is ... kind of a mess. I mean, I Ken> understand WHY it's a mess and why it's doing what it does. Ken> But let me explain (and I know that most people here know this Ken> stuff, but I want to restate my understanding in case it is Ken> wrong). Ken> My general understanding of the client preauth loop is that it Ken> tries to distinguish between "real" preauth mechanisms and Ken> "non-real" mechanisms that are just being used as a protocol Ken> extension. It will try to pick the "best" real mechanism it Ken> can do out of the list. We tried to addrcess this in the preauth framework, but implementations really haven't caught up, in part because there are a number of pre-framework mechanisms in play like pkinit, and in part because it's hard and standardization effort exceeded implementation effort in a number of places. The inten in the preauth framework model was effectively to do away with the loop entirely. You get a preauth required error with a number of PA sets (or singleton mechanisms). The mechanisms include hints that let you know whether you are likely to succeed with them. You pick one of the sets and go down that path. If it fails, it fails; you don't try more, and you don't take a preauth required error as a new set of things to try. The intent was also that the PA sets would give you enough information so that you could present all the UI at once. --Sam _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev