I have made some progress locating the problem which I would like to
share here.
When I am using openssl with the extensions file exactly as recommended
to create the client certificate and refer to the file in
/etc/krb5.conf, kinit works flawlessly with Public Key Algorithm
id-ecPublicKey / secp384r1. I can even use ECC for the CA certificate
without problems.
The problem is that we are using Yubikeys with the PIV function as
smartcards. Yubikey supports ECC with secp384r1.
But when I create a new key pair with ECC, sign the public key with
openssl with the same extension file, and try to use it, I get the
following situation
* When I do a kinit, connection is opened to the KDC and it sends the
message "pre-authentication required" back.
* After I enter the yubikey PIN, there is no more communication with
the KDC - so the problem is on the client as Greg has already proposed
* kinit reports that the certificate from the yubikey has been read
and that the CN is OK (I am using pkinit_cert_match...).
* But then, I am getting the following message from opensc:
P:296321; T:0x140609979246400 17:33:26.054 [opensc-pkcs11]
pkcs11-object.c:697:C_SignInit: C_SignInit() = CKR_KEY_HANDLE_INVALID
So there is some problem with opensc-pkcs11. Interestingly I am using
the same Yubikey successfully with pam-pkcs11 to authenticate without
problems.
I have some hope that I am seeing a configuration issue, even though it
is weird that this would depend on the public key algorithm.
On 11/17/23 06:53, Greg Hudson wrote:
On 11/15/23 23:22, Goetz Golla wrote:
* Does MIT Kerberos support PKINIT with Elliptic Curves as described
in RFC 5349 ?
A P-384 EC client certificate works in my tests, with either krb5-1.17
or the current code, as long as the KDC is also running MIT krb5.
Ken is correct that there is a hardcoded reference to RSA in the source:
p7si->digest_enc_alg->algorithm =
OBJ_nid2obj(NID_sha256WithRSAEncryption);
and this probably means the CMS signature has a piece of incorrect
metadata when an EC certificate is used. But this field is not used
when generating the signature contents and is ignored by OpenSSL when
verifying the signature (when the KDC is running MIT krb5).
* Could it be that for ECC client certificates the KDC certificate
also needs the be ECC ?
In my tests the KDC certificate was an RSA cert, so no.
Of course, my experience doesn't match yours. From your trace, I
believe that the failure occurs in the client code, not on the KDC, so
inspecting the KDC logs would not help. But the trace log does not
contain any detailed information about the failure.
You can sometimes improve the diagnostics for PKINIT failures by
removing the long-term keys associated with the principal, so that
authentication does not fall back to encrypted timestamp:
kadmin purgekeys -all user
If that doesn't help, it may be necessary to build the code with
debugging symbols and and step through it to find out where it is
failing.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
