[PATCH] 331-333 add support for synchronous key archival and recovery requests.
Hi all, This is in support of Ticket https://fedorahosted.org/pki/ticket/2532 This is preliminary set of patches - just so you can see what I'm doing in case I need to change anything. Note: With the changes, you can archive a secret like this: pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID "test_1" pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID "test_2" --express The first invocation will archive a secret and create an archival request in LDAP. The second will create one only in memory - and will not store it in LDAP. You can of course, see the requests created using - pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-find For retrieving the secret, you can do either: pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express The first will retrieve the secret while creating a retrieval request. The second will create a retrieval request only in memory, and will not write it to LDAP. In both cases, there should be audit logs both for retrieval and archival. Thanks, Ade
Based on feedback by Endi, I have reworked the patches. As Endi pointed out, it makes little sense for the client to determine whether or not a request is stored to ldap or not. This should be a server side decision. Accordingly, I have modified retrieveKey() as follows: When clients call retrieveKey(), three possible alternatives now obtain: 1. client passes in an approved request. Request is processed and the secret is retrieved. 2. client passes in key_id and wrapping parameters and either: a) request can be processed immediately and synchronously and request is created, and secret is returned. b) request cannot be processed immediately. Recovery request is created and request_id returned to the client Depending on server configuration, the requests in case (2a) will be stored in ldap or will be ephemeral (in memory only). More complicated realm based logic to determine if requests can be processed synchronously (and possibly ephemerally) will be added in a later patch. Python client patches coming soon as well. *********************************************************************** You can test the patches as follows: (archive and retrieve a passphrase) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "foobar" --clientKeyID "test_1" pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc (retrieve the passphrase using an approved recovery request) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-review --action approve 0x36 pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --requestID 0x36 The above should create requests (archival and recovery) in LDAP. Add the following to CS.cfg (and restart the KRA): kra.ephemeral=true Redo the above tests, and no requests should be written to LDAP. Finally, test a case where more than one approval is needed. Add the following to CS.cfg and restart the KRA. kra.noOfRequiredSecurityDataRecoveryAgents=2 pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc This should return a recovery request ID (which will be written to LDAP). You will need another agent to approve this request before it can be used to retrieve the key. Ade On Fri, 2016-11-04 at 16:11 -0400, Ade Lee wrote:
Hi all,
This is in support of Ticket https://fedorahosted.org/pki/ticket/2532
This is preliminary set of patches - just so you can see what I'm doing in case I need to change anything.
Note: With the changes, you can archive a secret like this:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" -- clientKeyID "test_1"
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" -- clientKeyID "test_2" --express
The first invocation will archive a secret and create an archival request in LDAP. The second will create one only in memory - and will not store it in LDAP.
You can of course, see the requests created using -
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-find
For retrieving the secret, you can do either:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express
The first will retrieve the secret while creating a retrieval request. The second will create a retrieval request only in memory, and will not write it to LDAP.
In both cases, there should be audit logs both for retrieval and archival. Thanks, Ade
Thanks for reviews (Endi and Jack). Pushed to master with a few minor changes to auditing. Ade On Wed, 2016-11-09 at 10:59 -0500, Ade Lee wrote:
Based on feedback by Endi, I have reworked the patches. As Endi pointed out, it makes little sense for the client to determine whether or not a request is stored to ldap or not. This should be a server side decision.
Accordingly, I have modified retrieveKey() as follows:
When clients call retrieveKey(), three possible alternatives now obtain:
1. client passes in an approved request. Request is processed and the secret is retrieved. 2. client passes in key_id and wrapping parameters and either: a) request can be processed immediately and synchronously and request is created, and secret is returned. b) request cannot be processed immediately. Recovery request is created and request_id returned to the client Depending on server configuration, the requests in case (2a) will be stored in ldap or will be ephemeral (in memory only). More complicated realm based logic to determine if requests can be processed synchronously (and possibly ephemerally) will be added in a later patch.
Python client patches coming soon as well.
********************************************************************* ** You can test the patches as follows:
(archive and retrieve a passphrase) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "foobar" --clientKeyID "test_1" pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc
(retrieve the passphrase using an approved recovery request) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-review --action approve 0x36 pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --requestID 0x36
The above should create requests (archival and recovery) in LDAP. Add the following to CS.cfg (and restart the KRA):
kra.ephemeral=true
Redo the above tests, and no requests should be written to LDAP.
Finally, test a case where more than one approval is needed. Add the following to CS.cfg and restart the KRA.
kra.noOfRequiredSecurityDataRecoveryAgents=2
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-retrieve --keyID 0xc
This should return a recovery request ID (which will be written to LDAP). You will need another agent to approve this request before it can be used to retrieve the key.
Ade
On Fri, 2016-11-04 at 16:11 -0400, Ade Lee wrote:
Hi all,
This is in support of Ticket https://fedorahosted.org/pki/ticket/25 32
This is preliminary set of patches - just so you can see what I'm doing in case I need to change anything.
Note: With the changes, you can archive a secret like this:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" -- clientKeyID "test_1"
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" -- clientKeyID "test_2" --express
The first invocation will archive a secret and create an archival request in LDAP. The second will create one only in memory - and will not store it in LDAP.
You can of course, see the requests created using -
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-find
For retrieving the secret, you can do either:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express
The first will retrieve the secret while creating a retrieval request. The second will create a retrieval request only in memory, and will not write it to LDAP.
In both cases, there should be audit logs both for retrieval and archival. Thanks, Ade
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Looked over all these and it looks good. Post checkin ACK :) Just a couple of questions: 1. Code like this: if (!synchronous) { + // Has to be in this state or it won't go anywhere. + request.setRequestStatus(RequestStatus.BEGIN); + queue.processRequest(request); + } else { + kra.processSynchronousRequest(request); + } I know we are handling the synchronous request with a processor and such, but the standard async request is being handled with the same queue method. Would it look nicer to have a layer for the standard case, like processAsynchRequest? No big deal. 2. Did we do a sanity sweep of the various scenarios to make sure that they refactor is good with respect to legacy code paths? I"m sure we have but was just asking. 3. Also I realize that the "realm" param is not yet supported but is a hook for future code, if we have to touch anything again, might help to give a comment in the key methods as to why it is not yet being used. thanks, jack ----- Original Message -----
From: "Ade Lee" <alee@redhat.com> To: pki-devel@redhat.com Sent: Friday, November 4, 2016 1:11:03 PM Subject: [Pki-devel] [PATCH] 331-333 add support for synchronous key archival and recovery requests.
Hi all,
This is in support of Ticket https://fedorahosted.org/pki/ticket/2532
This is preliminary set of patches - just so you can see what I'm doing in case I need to change anything.
Note: With the changes, you can archive a secret like this:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID "test_1"
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-archive --passphrase "ooga booga" --clientKeyID "test_2" --express
The first invocation will archive a secret and create an archival request in LDAP. The second will create one only in memory - and will not store it in LDAP.
You can of course, see the requests created using -
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h `hostname` -p 8443 key-request-find
For retrieving the secret, you can do either:
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h aleeredhat.laptop -p 8443 key-retrieve --keyID 0x5 --express
The first will retrieve the secret while creating a retrieval request. The second will create a retrieval request only in memory, and will not write it to LDAP.
In both cases, there should be audit logs both for retrieval and archival. Thanks, Ade _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (2)
-
Ade Lee -
John Magne