Semantics for multiple pkinit_anchors/pkinit_pool lines

[Ken Hornstein]

>> - It seems like nearly all preauth errors are flattened down to the
>>   error KRB5_PREAUTH_FAILED.
>
>Or KRB5KDC_ERR_PREAUTH_FAILED if they come from the KDC.

... does that happen?  Because from what I'm seeing, even if a mechanism
returns KRB5KDC_ERR_PREAUTH_FAILED it still ends up returning
KRB5_PREAUTH_FAILED.  Really, though, in terms of messages delivered to
a user it's a choice between "Generic preauthentication failure" and
"Preauthentication failed".  And they're both lousy.

>>   So I understand that the "real" error is being appended to the error
>>   message, which is fine.  But this presents a problem in practice, as
>>   many programs don't display the error message string and just the
>>   output of com_err on the error code.
>
>Our programs or out-of-tree programs?

Well, SPECIFICALLY, I am thinking of kinit and Leash.  The relevant
code from kinit:

        /* If reply decryption failed, or if pre-authentication failed and we
         * were prompted for a password, assume the password was wrong. */
        if (ret == KRB5KRB_AP_ERR_BAD_INTEGRITY ||
            (pwprompt && ret == KRB5KDC_ERR_PREAUTH_FAILED)) {
            fprintf(stderr, _("%s: Password incorrect while %s\n"), progname,
                    doing);
        } else {
            com_err(progname, ret, _("while %s"), doing);
        }

Leash is more complicated, but from what I have heard from our Windows
developers it's a similar thing: the error message that is displayed is
"Generic Preauthentication Failure".  (I realize you mention what happens
with kinit later).

>>   And the specific issue we're
>>   running into is if a user is using the SAM2 preauth mechanism and
>>   they enter the wrong password, instead of saying "Password incorrect",
>>   they get "Preauth failed", because the correct error IS returned by the
>>   preauth mechanism but never makes it up to the application.
>
>kinit specifically looks for KRB5KRB_AP_ERR_BAD_INTEGRITY and
>KRB5KDC_ERR_PREAUTH_FAILED after prompting for a password (see kinit.c
>line 810).  The second check could probably be extended to cover
>KRB5_PREAUTH_FAILED as well.

So if THAT is done, I am wondering what would happen if a user is
prompted for a PIN (from a PKCS11 mechanism) but got some weird PKINIT
failure.  "Password incorrect" would be obviously wrong in that case.

Hm, it looks like that WON'T happen, because that code is looking
for KRB5_PROMPT_TYPE_PASSWORD and it looks like the PKINIT plugin
is using KRB5_PROMPT_TYPE_PREAUTH to prompt for a PIN.

>>   I have done enough stuff with the preauth code over the years to
>>   know that it is ... complicated.  So I could believe that returning
>>   the "correct" error code could cause some unexpected issues; I do
>>   not believe that it would, but I could be wrong.
>
>There's a bit of history here:
>
>* In commit 632260bd1fccfb420f0827b59c85c329203eafc9 (ticket 7517) we
>started doing what you proposed, returning the error code from the first
>failed non-informational preauth mech.
>
>* In commit 560e11dabb63b141df29c54aaa2e120309a1e021 (ticket 8457) we
>switched to wrapping with KRB5_PREAUTH_FAILED, because the S4U2Self code
>expected to see that error code during realm identification.

Ahhh, okay, THAT was what I was worried about; we don't use S4U2Self
so we didn't run into that issue.

>* In commit 9d6847c8f0187a0dd6466420335b5460de5c449e we added a better
>internal API for realm identification, removing the consideration that
>led to the wrapping.
>
>So we could perhaps return to the ticket 7517 behavior.  But for the
>specific SAM-2 problem you describe, I think it would be better for
>krb5_get_init_creds_password() to recognize password-incorrect errors
>using the logic currently in kinit (extended to include client-side
>preauth errors).  There is currently no com_err code for "password
>incorrect", so we'd have to add one to k5e1_err.et.

I'm personally fine with that ... it would be nice to get rid of the
occasional stray "Decrypt integrity check failed" I see with third
party programs.

--Ken