Nuances of MIT Kerberos prompting

Russ Allbery eagle at eyrie.org
Tue Mar 3 01:33:52 EST 2020


I'm finally revisiting PKINIT prompting in pam-krb5 and am trying to wrap
my head around some subtle nuances of behavior to be sure I'm doing
reasonable things.  Thus, a few questions:

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.

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?

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?

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.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>


More information about the Kerberos mailing list