Difference between revisions of "PKI-Revoke"

Revision as of 19:23, 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 column in the database: revoked.
2. Change the authenticate code to check for revoked status. Attemptes to authenticate using a revoked token will raise exception.Unauthorized()
3. 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.
4. Either way, at token timeout, the tokens will be removed from the table.
5. 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. This is to prevent a race condition attack where a user finds out about a revoked token and attempts to use it before the services
Services runnning auth_token middleware will query the Revocation list on a simple schedule.
1. The time out will be a configuration option.
2. The revocation list be a signed CMS document
3. The body of the revocation list will be the id_hash values of the tokens.
4. 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.
5. 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 3: / Line 3: @@
 # 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
+## Add an additional column in the database:  revoked.
+## Change the authenticate code to check for revoked status.  Attemptes to authenticate using a revoked token will  raise exception.Unauthorized()
 ## 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.
 ## GET /tokens/revoked/
-## Only exposed on the admin port
+## Only exposed on the admin port.
-## Services runnning auth_token middleware will query the Revocation list on a simple schedule.
+## This is to prevent a race condition attack where a user finds out about a revoked token and attempts to use it before the services
+# 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.
+## 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.