Ticket History #7596: PKINIT should allow missing DH param Q

thank you!
I applied the patch to the krb-1.11.1 source, compiled pkinit and installed it.
Unfortunately the test was not successful
The client shows the error 0x41 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED
But the log output of krbkdc changed:

crypto_check_cert_eku: found eku info in the cert
crypto_check_cert_eku: checking eku 1 of 3, allow_secondary = 0
crypto_check_cert_eku: found acceptable EKU, checking for digitalSignature
crypto_check_cert_eku: found digitalSignature KU
crypto_check_cert_eku: returning retval 0, valid_eku 1
verify_client_eku: returning retval 0, eku_accepted 1
p is not well-known group 2 dhparameter
bad group 2 q dhparameter
p is not well-known group 2 dhparameter
bad dh parameters
pkinit_verify_padata failed: creating e-data
pkinit_create_edata: creating edata for error -1765328319 (Key
parameters not accepted)
pkinit_fini_kdc_req_context: freeing reqctx at 0xd5ce50
pkinit_fini_req_crypto: freeing ctx at 0xd560e0
pkinit_fini_identity_crypto: freeing ctx at 0xd40640
pkinit_fini_plg_crypto: freeing context at 0xd3ee70
pkinit_server_plugin_fini: freeing context at 0xd2a220


On Fri, Mar 29, 2013 at 12:18 AM, Tom Yu via RT
<rt-comment@krbdev.mit.edu> wrote:

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


Interesting. Maybe try putting "aip = NULL;" right before the call to
M_ASN1_D2I_get_opt()?

now the pkinit phase looks good, but I still get "bad username or
password" on the windows client.
Eventvwr shows this error:
A Kerberos Error Message was received:
on logon session p130@kerberos.3ve.bmlv.at
Client Time: 20:11:58.0000 10/17/2022 Z
Server Time: 6:56:57.0000 3/30/2013 Z
Error Code: 0x41 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED
Extended Error:
Client Realm: kerberos.3ve.bmlv.at
Client Name: p130
Server Realm: kerberos.3ve.bmlv.at
Server Name: krbtgt/kerberos.3ve.bmlv.at
Target Name: krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at
Error Text: PREAUTH_FAILED
File: e
Line: 9fe
Error Data is in record data.

"Client Time" looks wrong, but the system time is set to 30.03.2013 08:10 UTC+1

On the network I see
AS-REQ
KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
AS-REQ
KRB Error: KDC_ERR_KEY_TOO_WEAK
AS-REQ
AS-REP

krbkdc -n:

pkinit_init_req_crypto: returning ctx at 0x1e2e2c0
pkinit_init_kdc_req_context: returning reqctx at 0x1e27010
processing KRB5_PADATA_PK_AS_REQ
CMS Verification successful
#0 cert= /C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
#1 cert= /DC=at/DC=bmlv/DC=3ve/DC=kerberos/CN=kerberos-DC-CA
crypto_retrieve_X509_sans: looking for SANs in cert =
/C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
crypto_retrieve_X509_sans: found 2 subject alt name extension(s)
crypto_retrieve_X509_sans: SAN type = 1 expecting 0
verify_client_san: Checking pkinit sans
verify_client_san: no pkinit san match found
verify_client_san: Checking upn sans
verify_client_san: upn san match found
verify_client_san: returning retval 0, valid_san 1
crypto_check_cert_eku: looking for EKUs in cert =
/C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
crypto_check_cert_eku: found eku info in the cert
crypto_check_cert_eku: checking eku 1 of 3, allow_secondary = 0
crypto_check_cert_eku: found acceptable EKU, checking for digitalSignature
crypto_check_cert_eku: found digitalSignature KU
crypto_check_cert_eku: returning retval 0, valid_eku 1
verify_client_eku: returning retval 0, eku_accepted 1
client sent dh params with 1024 bits, we require 2048
bad dh parameters
pkinit_verify_padata failed: creating e-data
pkinit_create_edata: creating edata for error -1765328319 (Key
parameters not accepted)
pkinit_fini_kdc_req_context: freeing reqctx at 0x1e27010
pkinit_fini_req_crypto: freeing ctx at 0x1e2e2c0
pkinit_verify_padata: entered!
pkinit_find_realm_context: returning context at 0x1df1790 for realm
'kerberos.3ve.bmlv.at'
pkinit_init_req_crypto: returning ctx at 0x1e2e7a0
pkinit_init_kdc_req_context: returning reqctx at 0x1e2ca90
processing KRB5_PADATA_PK_AS_REQ
CMS Verification successful
#0 cert= /C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
#1 cert= /DC=at/DC=bmlv/DC=3ve/DC=kerberos/CN=kerberos-DC-CA
crypto_retrieve_X509_sans: looking for SANs in cert =
/C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
crypto_retrieve_X509_sans: found 2 subject alt name extension(s)
crypto_retrieve_X509_sans: SAN type = 1 expecting 0
verify_client_san: Checking pkinit sans
verify_client_san: no pkinit san match found
verify_client_san: Checking upn sans
verify_client_san: upn san match found
verify_client_san: returning retval 0, valid_san 1
crypto_check_cert_eku: looking for EKUs in cert =
/C=AT/ST=Austria/L=Vienna/O=kerberos/CN=p130@kerberos.3ve.bmlv.at
crypto_check_cert_eku: found eku info in the cert
crypto_check_cert_eku: checking eku 1 of 3, allow_secondary = 0
crypto_check_cert_eku: found acceptable EKU, checking for digitalSignature
crypto_check_cert_eku: found digitalSignature KU
crypto_check_cert_eku: returning retval 0, valid_eku 1
verify_client_eku: returning retval 0, eku_accepted 1
p is not well-known group 2 dhparameter
good 2048 dhparams
pkinit_find_realm_context: returning context at 0x1df1790 for realm
'kerberos.3ve.bmlv.at'
pkinit_return_padata: entered!
KDC picked etype = 18
received DH key delivery AS REQ
building certificate chain
size of certificate chain = 2
cert #0: /C=AT/ST=Austria/L=Vienna/O=kerberos/CN=dc.kerberos.3ve.bmlv.at
mech = FS
pkinit_fini_kdc_req_context: freeing reqctx at 0x1e2ca90
pkinit_fini_req_crypto: freeing ctx at 0x1e2e7a0
^Cpkinit_fini_identity_crypto: freeing ctx at 0x1e07640
pkinit_fini_plg_crypto: freeing context at 0x1e05e70
pkinit_server_plugin_fini: freeing context at 0x1df1220

The pkinit succeeds on the KDC, but Windows seems to get confused with
the "Key parameters not accepted" error.

Authentication with Windows 7 + Smartcard:

Mar 30 08:30:37 kerberos.example.org krb5kdc[2584](info): AS_REQ (7
etypes {18 17 23 3 1 24 -135}) 192.168.56.101: NEEDED_PREAUTH:
p130@kerberos.3ve.bmlv.at for
krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at, Additional
pre-authentication required
Mar 30 08:30:39 kerberos.example.org krb5kdc[2584](info): preauth
(pkinit) verify failure: Key parameters not accepted
Mar 30 08:30:39 kerberos.example.org krb5kdc[2584](info): AS_REQ (9
etypes {12 15 18 17 23 3 1 24 -135}) 192.168.56.101: PREAUTH_FAILED:
p130@kerberos.3ve.bmlv.at for
krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at, Key parameters not
accepted
Mar 30 08:30:40 kerberos.example.org krb5kdc[2584](info): AS_REQ (9
etypes {12 15 18 17 23 3 1 24 -135}) 192.168.56.101: ISSUE: authtime
1364628640, etypes {rep=18 tkt=18 ses=18}, p130@kerberos.3ve.bmlv.at
for krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at
Mar 30 08:30:41 kerberos.example.org krb5kdc[2584](info): AS_REQ (9
etypes {12 15 18 17 23 3 1 24 -135}) 192.168.56.101: NEEDED_PREAUTH:
p130@kerberos.3ve.bmlv.at for
krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at, Additional
pre-authentication required

Authentication of Linux + Certificate
kinit -V -X X509_user_identity=FILE:///home/catmin/Desktop/exampleca/client.pem,/home/catmin/Desktop/exampleca/clientkey.pem
p130@kerberos.3ve.bmlv.at

Mar 30 08:31:31 kerberos.example.org krb5kdc[2584](info): AS_REQ (4
etypes {18 17 16 23}) 192.168.56.1: NEEDED_PREAUTH:
p130@kerberos.3ve.bmlv.at for
krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at, Additional
pre-authentication required
Mar 30 08:31:31 kerberos.example.org krb5kdc[2584](info): AS_REQ (4
etypes {18 17 16 23}) 192.168.56.1: ISSUE: authtime 1364628691, etypes
{rep=18 tkt=18 ses=18}, p130@kerberos.3ve.bmlv.at for
krbtgt/kerberos.3ve.bmlv.at@kerberos.3ve.bmlv.at
Mar 30 08:31:31 kerberos.example.org krb5kdc[2584](info): closing down fd 12

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


The above looks like a possible configuration problem. For some
reason, the Windows 7 client is sending 1024 bits, while the KDC
requires 2048 bits.


Is the above also from the same Windows 7 client during the same
authentication attempt?

Ignore missing Q in dh_params

Some implementations don't send the required Q value in dh_params, so
allow it to be absent.

(cherry picked from commit ed77a25c53ed6afd41372838f205a98a561a89fb)

https://github.com/krb5/krb5/commit/5d2c49df555fbf56d3b15a9096cad729525c5f74
Author: Tom Yu <tlyu@mit.edu>
Commit: 5d2c49df555fbf56d3b15a9096cad729525c5f74
Branch: krb5-1.11
src/plugins/preauth/pkinit/pkinit_crypto_openssl.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

Ticket 8398 (commit e5c77a11341a79e6af1e5aef7c587a5b75a9e378, "Add PKINIT support for OpenSSL 1.1.0", going into release 1.15) attempted to preserve this workaround using a custom ASN.1 type with an optional q parameter.  However, the same commit added a helper dup_dh_params() with error-checking on the results of BN_dup(), replacing the old code which had no error-checking.  This error-checking would erroneously trigger if q is unset in the DH parameters, causing server_process_dh() and therefore pkinit_server_return_padata() to return ENOMEM.

Since no one has reported the regression to my knowledge, I would guess that Microsoft fixed its bug and the workaround is no longer needed.  I have asked Microsoft dochelp for clarification of which versions omit the q value.

If we need to restore the workaround, dup_dh_params() can check for (oldq != NULL && q == NULL) instead of q == NULL.  Also, we could do the parsing more simply in OpenSSL 1.1 by trying d2i_DHxparams() and falling back to d2i_DHparams().  The latter function will read domain parameters using the PKCS#3 DHParameter type, which has no q value.  (OpenSSL 1.0 does not have DHxparams support, so we're stuck with custom encoding and decoding to handle the RFC 3279 type.)
 

Microsoft dochelp replied that Microsoft fixed their side of this issue in Windows 10, and that the final build of Windows 8.1 was the last version to not always send the q parameter.

Windows 8.1 has been out of mainstream support as of January 2018, and will hit end of life in January 2023.  Given our own release lag and the lack of complaints, I don't think it would be useful to restore the workaround at this point.