Nuances of MIT Kerberos prompting

[Greg Hudson]

On 3/3/20 1:33 AM, Russ Allbery wrote:
> 1. The normal prompter interface has a mechanism to send a "name" and a
>    "banner".  Neither of these are very well-documented, but the current
>    PAM module behavior is to output them both (name first, then banner) as
>    PAM_TEXT_INFO.
> 
>    I don't see any equivalent in the responder API.  How does that work?
>    Is the prompter called with the name and banner but an empty list of
>    prompts and the responder called with the actual questions, if both are
>    given?  In what order?  I naively would have expected some way to use
>    the responder interface to completely replace the prompter interface,
>    but that doesn't seem to be possible because name and banner aren't
>    supported.

The responder interface is targeted at an application that wants to have
knowledge of particular preauth mechanisms and present its own UI.  So
the responder question doesn't tell the application what text to present
to the user; instead, it presents a semantic question in terms of
concepts specific to the preauth mech.

The prompter acts as a fallback to the responder.  So if the responder
is present but does not answer a question the preauth mech needs to
proceed, the prompter is invoked (if present).

So, the responder doesn't strictly subsume the prompter; a caller who
wants to be told what textual questions to ask the user, or who doesn't
want to have specific knowledge of preauth mechanisms, must continue to
use the prompter.

> 2. Revisiting this message from many years ago:
> 
>    http://mailman.mit.edu/pipermail/kerberos/2013-May/018973.html
> 
>    the suggestion for use_pkinit was to have a prompter that declined to
>    respond to password questions and only passed along preauth questions.
>    This would be an alternative approach to using the responder API.
>    However, this prompts a question: how does a prompter decline to
>    respond to a question?  Should the prompter return failure if
>    KRB5_PROMPT_TYPE_PASSWORD appears anywhere in krb5_get_prompt_types,
>    presumably without displaying the name or banner?  If so, what status
>    code?

I think that would work.  Any error code should work to disable a
preauth mech which requires the password (encrypted timestamp, encrypted
challenge, SPAKE).  I'll suggest EIO, which is the error code returned
by krb5_get_as_key_password() if no prompter is present.

> 3. How can I trigger MIT Kerberos to send a PKINIT prompt with multiple
>    identities so that I can test the code that prompts the user to select
>    one?  The code seems determined to prevent me from specifying multiple
>    pkinit_identities.  Only the first one in krb5.conf appears to be
>    honored and any subsequent ones are ignored, and kinit doesn't allow
>    X509_user_identity to be set more than once.  Do I *have* to have a
>    PKCS11 module to get to that code path, and I cannot access it with
>    FILE or PKCS12 identities?

I don't have a ready answer to this question; I can look into it if it's
still relevant given the other answers.

> Finally, more a bug report than a question, but MIT Kerberos 1.17, when
> given a PKCS12 identity file that's protected with a password (which is
> what I'm using to test PIN prompting) prompts for the password twice.  The
> second time appears to be during the krb5_verify_init_creds call.  What's
> going on here?  The user experience is a little odd.  kinit only prompts
> once, but I think that's because kinit never calls krb5_verify_init_creds.

I can't account for this.  krb5_verify_init_creds() is only supposed to
make TGS requests, not AS requests, so it shouldn't be doing any preauth
(and therefore shouldn't be doing any prompting).