$ pki -d /opt/rhqa_pki/certs_db -c Secret123 -h dhcp207-176.lab.eng.pnq.redhat.com -p 30044 -n "KRA3_agentV" key-generate pkitemp1 --key-algorithm RC4 --key-size -1 --usages wrap,unwrap,sign,encrypt,decrypt --------------------------- Key generation request info --------------------------- Request ID: 0x2e3 Type: symkeyGenRequest Status: complete # pki -d /opt/rhqa_pki/certs_db -c Secret123 -h dhcp207-176.lab.eng.pnq.redhat.com -p 30044 -n "KRA3_agentV" key-generate pkitemp1 --key-algorithm RC4 --key-size 1024 --usages wrap,unwrap,sign,encrypt,decrypt --------------------------- Key generation request info --------------------------- Request ID: 0x2e4 Key ID: 0x2d8 Type: symkeyGenRequest Status: complete
Per discussion with vakwetu: 10.2.3
The issue here is that the generation/archival of the initial RC4 key failed (due to the illegal negative key size). You can see this if you list the keys:
[nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test2 --key-algorithm RC4 --key-size -1 Enter Client Security Database Password: --------------------------- Key generation request info --------------------------- Request ID: 0x4 Type: symkeyGenRequest Status: complete [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-request-find --client test2 Enter Client Security Database Password: ----------------- 0 entries matched -----------------
This indicates that the request was accepted/completed, but it was unsuccessful. You can tell that it was not successful since you were not given a "Key ID" in the response.
Reusing a client ID that is not currently active is fine. We do prevent reuse of currently active client IDs. You can see this in the below example, along with the fact that a "Key ID" is returned in the response for a successful generation:
[nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test2 --key-algorithm RC4 --key-size 40 Enter Client Security Database Password: --------------------------- Key generation request info --------------------------- Request ID: 0x5 Key ID: 0x2 Type: symkeyGenRequest Status: complete [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-show 2 Enter Client Security Database Password: Key ID: 0x2 Client ID: test2 Status: active Algorithm: RC4 Size: 40 Owner: kraadmin [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test2 --key-algorithm AES --key-size 192 Enter Client Security Database Password: BadRequestException: Can not archive already active existing key!
The problem here is that we don't perform validity checking on the --key-size parameter for the RC4 algorithm. We do appear to be performing proper validity checking on the other algorithms:
[nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm AES --key-size 130 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm AES --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC2 --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC2 --key-size 7 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DES --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DES --key-size 40 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DES3 --key-size 40 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DES3 --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DESede --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm DESede --key-size 40 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm
The validation of key sizes is handled by JSS, not Dogtag. Specifically, we have the following in base/server/cms/src/com/netscape/cms/servlet/key/KeyRequestDAO.java:
import org.mozilla.jss.crypto.KeyGenAlgorithm; ... KeyGenAlgorithm alg = KEYGEN_ALGORITHMS.get(algName); ... if (!alg.isValidStrength(keySize.intValue())) { throw new BadRequestException("Invalid key size for this algorithm"); }
This is a bug in JSS in mozilla/security/jss/org/mozilla/jss/crypto/KeyGenAlgorithm.java. As can be seen below, the RC4 strength validator method always returns True:
public static final KeyGenAlgorithm RC4 = new KeyGenAlgorithm(CKM_RC4_KEY_GEN, "RC4", new KeyStrengthValidator() { public boolean isValidKeyStrength(int strength) { return true; } }, null, null);
RC4 acceptable key sizes should really be between 40 and 2048 bits. The RC4 strength validator method should look like this:
public static final KeyGenAlgorithm RC4 = new KeyGenAlgorithm(CKM_RC4_KEY_GEN, "RC4", new KeyStrengthValidator() { public boolean isValidKeyStrength(int strength) { return strength>=40 && strength <= (256*8); } }, null, null);
With the above changes to JSS, the RC4 key size validation performs correctly:
[nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC4 --key-size -1 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC4 --key-size 39 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC4 --key-size 2049 Enter Client Security Database Password: BadRequestException: Invalid key size for this algorithm [nathank@rover client]$ pki -n "PKI Administrator for home.orderlychaos.org" key-generate test3 --key-algorithm RC4 --key-size 40 Enter Client Security Database Password: --------------------------- Key generation request info --------------------------- Request ID: 0x7 Key ID: 0x3 Type: symkeyGenRequest Status: complete
I have filed a Fedora 20 bug against JSS for this issue here:
https://bugzilla.redhat.com/show_bug.cgi?id=1133717
Closing this, as it's not a Dogtag bug as described in the comments above. Proper RC4 key size validation will be performed when the JSS bug in comment 5 is fixed.
What about values which are in range between 40 and 2048 (which are negative), Should they also be valid ? example -40, -128, -1024 ?
[root@pki2 dogtag]# pki -d /opt/rhqa_pki/certs_db -c Secret123 -h pki2.example.org \ -p 30044 -n "KRA3_agentV" key-generate test8 --key-algorithm RC4 --key-size -40 --------------------------- Key generation request info --------------------------- Request ID: 0xaf Key ID: 0xaf Type: symkeyGenRequest Status: complete [root@pki2 dogtag]# pki -d /opt/rhqa_pki/certs_db -c Secret123 \ -h pki2.example.org -p 30044 -n "KRA3_agentV" key-generate test9 \ --key-algorithm RC4 --key-size -128 --------------------------- Key generation request info --------------------------- Request ID: 0xb0 Key ID: 0xb0 Type: symkeyGenRequest Status: complete
Metadata Update from @mrniranjan: - Issue set to the milestone: 10.2.3
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1679
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.