Nuances of MIT Kerberos prompting

[Russ Allbery]

Greg Hudson <ghudson at 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 thoron at 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.ORG at EYRIE.ORG
1583711787.103200: PKINIT client matched KDC principal krbtgt/EYRIE.ORG at 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 (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>