auth_token middleware does not check if an endpoint is in the service catalog

[Adam Young]

We include the catalog in the token, but it is not checked. Thus, a token that is intended for a subset of the endpoints can be used on additional endpoints. This prevents a user from creating a token specific to an endpoint. The comparable mechanism is service tickets in Kerberos. If a rogue service gets a ticket in Kerberos, it cannot reuse that ticket elsewhere. WIth the current token scheme, all tokens on a compromised server are at risk of being abused throughout an openstack deployment.

[Adam Young (ayoung)]

http://content.dell.com/us/en/enterprise/d/large-business/it-security-design

[Russell Bryant (russellb)]

Is this a vulnerability or a weakness in the current design?

If it's just something that should be improved, that's fine. In that case we should make the bug public and treat it as a "security hardening" issue.

We typically only leave bugs private and go through the embargo process for exploitable vulnerabilities.

[Adam Young (ayoung)]

Weakness in the current design. Figured I would be careful and start with it embargoed, but it is really "security hardening" as there is no known exploit for the issue.

[Russell Bryant (russellb)]

Great, thanks for the clarification. It's always good to start that way. I'm going to open this issue now.

[Thierry Carrez (ttx)]

Russell: made the bug "public". We should keep "Public security" for stuff that are vulnerabilities but where posted/fixed publicly, and use "Public" with "security" tag set for strengthening features.

[Morgan Fainberg (mdrnstm)]

This is not part of the scope of keystonemiddleware. We do not deny based up on the endpoint/catalog.