[38704] in Kerberos
Re: Nuances of MIT Kerberos prompting
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Mar 9 15:33:29 2020
From: Russ Allbery <eagle@eyrie.org>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <62df0d03-96fb-6a20-5cfb-15b9b9810ca5@mit.edu> (Greg Hudson's
message of "Mon, 9 Mar 2020 15:20:28 -0400")
Date: Mon, 09 Mar 2020 12:30:23 -0700
Message-ID: <8736ah8gxc.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Greg Hudson <ghudson@mit.edu> writes:
> Yes. For this prompter call, name is NULL, banner is the formatted
> expiration warning, and num_prompts is 0.
Thanks!
> Ah, two responder calls, not two prompter calls. I was looking at the
> wrong code paths.
Oh, sorry, poor bug report on my part.
> Now that I look a the PKINIT responder logic, I agree that there is a
> bug. In the second call to k5_preauth(), we are processing the KDC
> PKINIT padata supplied alongside the issued ticket, in order to
> authenticate the KDC response and set the correct reply key. PKINIT
> does not need access to client certificates at this stage, but
> pkinit_client_prep_questions() re-asks questions for its recorded
> identities without checking the padata type or any other state that
> would indicate where it is in the process. I will file a ticket.
Thanks!
> (The real reason kinit isn't affected is that it doesn't use a responder
> callback.)
Yes, that makes perfect sense in retrospect. I should have started with
gdb before speculating.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
