Greg Hudson <ghud...@mit.edu> writes: > 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.
I think the reason why I am confused by this is that Heimdal uses the prompter to pass along informational messages such as "your principal is about to expire," and I wasn't sure how MIT Kerberos would do the same thing with the responder interface. But maybe it doesn't present those messages, or uses the prompter for them even if a responder is provided and answers the actual questions? > 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. I've been tentatively using KRB5_LIBOS_CANTREADPWD since that seems more specific. Okay, looking at this some more, I think I'm going to throw out my responder implementation and go back to using a prompter, but instead decline to reply if krb5_get_prompt_types() indicates that the prompt is for a password. > I don't have a ready answer to this question; I can look into it if it's > still relevant given the other answers. It won't be, at least for me. >> 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). Yeah, I find it puzzling. I think it's during verify because if I configure the test suite to not respond to that second prompt at all, everyting still succeeds, so failure to reply to the second prompt is ignored. But I'm not sure what's going on. Here's the trace output, but it's not very useful since it seems to end after the authentication and doesn't include the verify attempt. 1583711786.155739: Getting initial credentials for tho...@eyrie.org 1583711786.155741: Sending unauthenticated request 1583711786.155742: Sending request (199 bytes) to EYRIE.ORG 1583711786.155743: Resolving hostname kerberos.eyrie.org 1583711786.155744: Initiating TCP connection to stream 166.84.7.155:88 1583711786.155745: Sending TCP request to stream 166.84.7.155:88 1583711786.155746: Received answer (309 bytes) from stream 166.84.7.155:88 1583711786.155747: Terminating TCP connection to stream 166.84.7.155:88 1583711786.155748: Response was from master KDC 1583711786.155749: Received error from KDC: -1765328359/Additional pre-authentication required 1583711786.155752: Preauthenticating using KDC method data 1583711786.155753: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133) 1583711786.155754: Selected etype info: etype aes256-cts, salt "EYRIE.ORGthoron", params "" 1583711786.155755: Received cookie: MIT 1583711786.155756: PKINIT initial PKCS12_parse with no password failed 1583711786.155757: Preauth module pkinit (147) (info) returned: 0/Success 1583711786.155758: PKINIT client received freshness token from KDC 1583711786.155759: Preauth module pkinit (150) (info) returned: 0/Success 1583711786.155760: PKINIT initial PKCS12_parse with no password failed 1583711786.155761: PKINIT loading CA certs and CRLs from FILE 1583711786.155762: PKINIT client computed kdc-req-body checksum 9/5200E986ED922B591C567068EBF6AD19A276D73F 1583711786.155764: PKINIT client making DH request 1583711787.103188: Preauth module pkinit (16) (real) returned: 0/Success 1583711787.103189: Produced preauth for next request: PA-FX-COOKIE (133), PA-PK-AS-REQ (16) 1583711787.103190: Sending request (2650 bytes) to EYRIE.ORG 1583711787.103191: Resolving hostname kerberos.eyrie.org 1583711787.103192: Initiating TCP connection to stream 166.84.7.155:88 1583711787.103193: Sending TCP request to stream 166.84.7.155:88 1583711787.103194: Received answer (2372 bytes) from stream 166.84.7.155:88 1583711787.103195: Terminating TCP connection to stream 166.84.7.155:88 1583711787.103196: Response was from master KDC 1583711787.103197: Processing preauth types: PA-PK-AS-REP (17) 1583711787.103198: PKINIT client verified DH reply 1583711787.103199: PKINIT client found id-pkinit-san in KDC cert: krbtgt/eyrie....@eyrie.org 1583711787.103200: PKINIT client matched KDC principal krbtgt/eyrie....@eyrie.org against id-pkinit-san; no EKU check required 1583711787.103201: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/1BD3 1583711787.103202: Preauth module pkinit (17) (real) returned: 0/Success 1583711787.103203: Produced preauth for next request: (empty) 1583711787.103204: AS key determined by preauth: aes256-cts/1BD3 1583711787.103205: Decrypted AS reply; session key is: aes256-cts/8D62 1583711787.103206: FAST negotiation: available -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos