Difference between revisions of "PKI-Revoke"

Revision as of 17:35, 6 August 2012

Changes to support revocation of PKI tokens

Revoked tokens must be recorded, not merely removed from the tokens backend. To effect this there are two choices:
1. Add an additional collumn in the database: revoked. Change the authenticate code to check for revoked status
2. Create an additional table: revoked_tokens. Revoked tokens will be removed from the tokens table just as they are now, and added to the revoked_tokens table.
3. Either way, at token timeout, the tokens will be removed from the table.
Once revoked, a token cannot be unrevoked.
The Keystone server will expose a list of revoked tokens exposed in an URL.
1. GET /tokens/revoked/
2. Only exposed on the admin port
3. Services runnning auth_token middleware will query the Revocation list on a simple schedule.
4. The time out will be a configuration option.
5. The revocation list be a signed CMS document
6. The body of the revocation list will be the id_hash values of the tokens.
7. If a token authentication request comes in to the auth_token middle and the service does not have a recent revocation list, it is fetched from keystone.
  1. If the Keystone server cannot be reached, authentication will fail.
Future enhancements:
1. wait a random amount of time and then requery the Keystone server.
2. Support as set of Keystone servers where the policy for revocation checking can vary per server.
3. Support a setup where a subset of the Keystone serversare not be directly accessible. In those cases, one Keystone server can proxy the revocation list for another server.

@@ Line 2: / Line 2: @@
 Changes to support revocation of PKI tokens
-.  Revoked tokens must be recorded, no merely removed from the tokens backend.
+# Revoked tokens must be recorded, not merely removed from the tokens backend.  To effect this there are two choices:
+## Add an additional collumn in the database:  revoked. Change the authenticate code to check for revoked status
-. The Keystone server to have a list of revoked tokens exposed in an URL.  Then, as service like Glance or Nova can query the Revocation list on a simple schedule.  The time out would be configurable, of course.  This will be exposed as a signed CMS  document, just like the tokens, in order to prove revokation.
+## Create an additional table: revoked_tokens.  Revoked tokens will be removed from the tokens table just as they are now, and added to the revoked_tokens table.
+## Either way,  at token timeout, the tokens will be removed from the table.
-.  Once revoked, a token cannot be unrevoked.
+# Once revoked, a token cannot be unrevoked.
+# The Keystone server will expose a list of revoked tokens exposed in an URL.
-.  If a token authentication request comes in to the auth_token middle and the service does not have a recent revocation list, it is fetched from keystone.  If the Keystone server cannot be reached, authentication will fail.   A future enhancement: wait a random amount of time and then requery the Keystone server.
+## GET /tokens/revoked/
+## Only exposed on the admin port
-. In the future, I would like to make the set of Keystone servers a configurable list, and the policy for revocation checking should be able to vary per server:  some Keystone servers in a federated approach might not be accessible.  In those cases,  it might be necessary for one Keystone server to proxy the revocation list for another server.
+## Services runnning auth_token middleware will query the Revocation list on a simple schedule.
+## The time out will be a configuration option.
+## The revocation list  be a signed CMS  document
+## The body of the revocation list will be the id_hash values of the tokens.
+## If a token authentication request comes in to the auth_token middle and the service does not have a recent revocation list, it is fetched from keystone.
+### If the Keystone server cannot be reached, authentication will fail.
+# Future enhancements:
+## wait a random amount of time and then requery the Keystone server.
+## Support as  set of Keystone servers where the  policy for revocation checking can vary per server.
+## Support a setup where a subset of the Keystone serversare not be directly accessible.  In those cases, one Keystone server can proxy the revocation list for another server.