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). ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos