[krbdev.mit.edu #7596] PKINIT should allow missing DH param Q

[Tom Yu via RT]

"Reinhard Kugler via RT" <rt-comment at krbdev.mit.edu> writes:

> I temporarily removed the check of the dh key length
> in pkinit_crypto_openssl.c
>
>     /* KDC SHOULD check to see if the key parameters satisfy its policy */
>     dh_prime_bits = BN_num_bits(dh->p);
>     /*if (minbits && dh_prime_bits < minbits) {
>         pkiDebug("client sent dh params with %d bits, we require %d\n",
>                  dh_prime_bits, minbits);
>         goto cleanup;
>     }*/
>
> pkinit succeeded and windows was able to acquire a TGT

Thanks for the additional information.  Based on your previous logs,
it looks like the Windows client makes the following requests:

1. AS-REQ, no preauth -> KRB-ERROR, additional preauth needed

2. AS-REQ, PKINIT, 1024-bit DH -> KRB-ERROR, bad key params

3. AS-REQ, PKINIT, 2048-bit DH -> AS-REP

4. AS-REQ, no preauth or unknown preauth -> KRB-ERROR, additional
   preauth needed

Windows is possibly failing to handle the DH parameter negotiation
correctly.  Interestingly, Windows is including the PKINIT special
enctypes on request #4, but probably omitting the actual PKINIT
preauth.

Also, it seems that the compile-time constant that establishes the
default DH modulus size serves as a lower bound on the configurable DH
modulus size, so the configuration setting "pkinit_dh_min_bits = 1024"
has no effect because the compiled-time constant is 2048:

    pkinit_init_kdc_profile: invalid value (1024) for
    pkinit_dh_min_bits, using default value (2048) instead

This happens in pkinit_srv.c:pkinit_init_kdc_profile().

Getting more detailed trace information from the Windows client would
be useful, but I think Windows 7 might have made that more difficult
(changed trace logging to a proprietary binary format?).  I will look
around to see what I can find on this topic.