in our organisation we are successfully using PKINIT with RSA 2048
client certificates for many years. We are now trying to move to ECC >certificates with the curve secp384r1.
All attempts have been unsuccessful yet.
* Does MIT Kerberos support PKINIT with Elliptic Curves as described
in RFC 5349 ?
* Could it be that for ECC client certificates the KDC certificate
also needs the be ECC ?
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.
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.
I have mentioned this before, but ... is there any interest in adding additional trace points for every place where the old "pkiDebug" calls
are made? Hidden errors when doing PKINIT are the bane of my existence
and I feel that I'm not the only one. I understand there are concerns
about making the trace log too verbose but I think every error could
generate a trace message and it wouldn't add too much to the trace output when everything was working.
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.
P:296321; T:0x140609979246400 17:33:26.054 [opensc-pkcs11] >pkcs11-object.c:697:C_SignInit: C_SignInit() = CKR_KEY_HANDLE_INVALID
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 mentioned this before, but ... is there any interest in adding additional trace points for every place where the old "pkiDebug" calls
are made? Hidden errors when doing PKINIT are the bane of my existence
and I feel that I'm not the only one. I understand there are concerns
about making the trace log too verbose but I think every error could
generate a trace message and it wouldn't add too much to the trace output when everything was working.
I would be happy to have more trace logging to diagnose PKINIT errors,
but converting every pkiDebug() call probably wouldn't meet the criteria
for good trace logging. We've already made a few passes in this area,
most recently one from you which went into release 1.20 (commit >34625d594c339a077899fa01fc4b5c331a1647d0).
if ((r = id_cryptoctx->p11->C_SignInit(id_cryptoctx->session, &mech,
obj)) != CKR_OK) {
pkiDebug("C_SignInit: %s\n", pkcs11err(r));
return KRB5KDC_ERR_PREAUTH_FAILED;
}
I guess what I was thinking was maybe not EVERY pkiDebug() call, but
more all of the ones that report errors.
However, I believe Yubico provides a PKCS#11 module for Yubikeys; have
you tried that? The OpenSC people usually do a good job in terms of supporting a wide variety of cards but depending on how old the particular version of OpenSC you are using is you may be running into a compatibility issue.
--Ken
However, I believe Yubico provides a PKCS#11 module for Yubikeys; have
you tried that? The OpenSC people usually do a good job in terms of
supporting a wide variety of cards but depending on how old the particular >> version of OpenSC you are using is you may be running into a compatibility >> issue.
--Ken
Indeed the module provided by Yubico solved the issue. It is called
ykcs11 and is readily available in the linux package managers.
[14174] 1700562344.750583: PKINIT error: There are 3 certs, but there
must be exactly one.
We had it working in November with Yubico's libykcs11 in a lab and in >production tested by two independent people. Testing it again this year
it failed. We are in the process of finding out what exactly we have
tested in November.
I am really confused now. I thought that the problem was in the opensc
code and replacing it with Yubico's libykcs11, which officially supports
ECC, should fix it.
Now you seem to suggest that the problem is in the Kerberos code ?
I am a LITTLE surprised it worked! The MIT PKINIT plugin hard-codesHowever, I believe Yubico provides a PKCS#11 module for Yubikeys; haveIndeed the module provided by Yubico solved the issue. It is called
you tried that? The OpenSC people usually do a good job in terms of
supporting a wide variety of cards but depending on how old the particular >>> version of OpenSC you are using is you may be running into a compatibility >>> issue.
--Ken
ykcs11 and is readily available in the linux package managers.
the mechanism in the request; I guess the Yubico library ignores the mechanism given to it, which seems strange to me.
I have to ask ... are you SURE that it's using ECC? Because the code that uses the PKCS#11 library is actually generating a PKCS#1 digest. I was
under the impression that ECC signatures are in a different format, so
I am puzzled how it works at all.
But here is some snippets of the PKCS#11 code in MIT Kerberos:
When specifying the search parameters to find the private key:
keytype = CKK_RSA;
attrs[nattrs].type = CKA_KEY_TYPE;
attrs[nattrs].pValue = &keytype;
attrs[nattrs].ulValueLen = sizeof keytype;
nattrs++;
When setting the key signing mechanism:
/*
* We'd like to use CKM_SHA256_RSA_PKCS for signing if it's available, but
* historically many cards seem to be confused about whether they are
* capable of mechanisms or not. The safe thing seems to be to ignore the
* mechanism list, always use CKM_RSA_PKCS and calculate the sha256 digest
* ourselves.
*/
id_cryptoctx->mech = CKM_RSA_PKCS;
Those are all hardcoded use of RSA keys and signing mechanisms and it
doesn't handle ECC at all. So unless the Yubico library ignored the
key type and mechanism (which I think would be extremely unlikely but
not impossible) I suspect you were using RSA back during your original testing and didn't realize it.
--Ken
Its good to know the reason why MIT Kerberos cannot handle EC
certificates right now.
So is there a way to submit a feature request for ECDSA support in MIT >Kerberos ?
On 1/11/24 15:41, Ken Hornstein wrote:
But here is some snippets of the PKCS#11 code in MIT Kerberos:
When specifying the search parameters to find the private key:
keytype = CKK_RSA;
attrs[nattrs].type = CKA_KEY_TYPE;
attrs[nattrs].pValue = &keytype;
attrs[nattrs].ulValueLen = sizeof keytype;
nattrs++;
When setting the key signing mechanism:
/*
* We'd like to use CKM_SHA256_RSA_PKCS for signing if it's available, but
* historically many cards seem to be confused about whether they are
* capable of mechanisms or not. The safe thing seems to be to ignore the
* mechanism list, always use CKM_RSA_PKCS and calculate the sha256 digest
* ourselves.
*/
id_cryptoctx->mech = CKM_RSA_PKCS;
Those are all hardcoded use of RSA keys and signing mechanisms and it doesn't handle ECC at all. So unless the Yubico library ignored the
key type and mechanism (which I think would be extremely unlikely but
not impossible) I suspect you were using RSA back during your original testing and didn't realize it.
--Ken
Its good to know the reason why MIT Kerberos cannot handle EC
certificates right now.
I know that NIST is happy with RSA 2048, but in Europe RSA >= 3072 is
already mandatory,
and this key size makes small devices like the
Yubikeys very slow when generating the keys. In fact, Yubikeys only
support RSA <=2048.
So is there a way to submit a feature request for ECDSA support in MIT Kerberos ?
So is there a way to submit a feature request for ECDSA support in MIT Kerberos ?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:50:49 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,500 |