Using PKINIT with ECC

[Goetz Golla]

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.