[krbdev.mit.edu #8885] PKINIT calls responder twice

"Greg Hudson via RT" <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.bugs
Message-ID <[email protected]>
Mon Mar 09 15:33:03 2020: Request 8885 was acted upon.
 Transaction: Ticket created by [email protected]
       Queue: krb5
     Subject: PKINIT calls responder twice
       Owner: Nobody
  Requestors: [email protected]
      Status: new
 Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8885 >


During a PKINIT AS-REQ, there are two rounds of client padata processing, one
to generate the request and one to validate the KDC response and compute the
reply key.

During the first round, pkinit_client_prep_questions() calls
pkinit_identity_initialize(), which calls crypto_load_certs() with
defer_id_prompts=TRUE. This accumulates a list of identities in
id_cryptoctx->deferred_ids. pkinit_client_prep_questions () then generates a
PKINIT question containing the list of identities to be prompted for.

During the second round, pkinit_client_prep_questions() is again called. The
pkinit_identity_initialize() call is skipped (because
reqctx->identity_initialized is true), but the list of deferred identities is
still present, so a question is again generated. PKINIT does not need access to
client certificates while processing the KDC response, so the question is
pointless and creates a bad user experience.

The simplest way to to suppress the second question is probably to check that
the padata type is KRB5_PADATA_PK_AS_REQ.

The double-responder behavior is already visible in t_pkinit.py tests, such as
the "FILE identity, password on key (responder)". We simply need to count the
number of "OK:" messages in the output to see how many responder calls are
made.

Reported by Russ Allbery.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.