Overview

In this scenario the |EU| has just signed an |SLA| which on implementation will trigger the provisioning of a few secure web containers, that in this scenario, and in accordance with the signed |SLA|, are to be deployed on |Rackspace|'s cloud infrastructure as |VM|'s under the control of the |SPECS| platform.

The key aspect on which we focus in this scenario, pertaining to the subject of credential management, is how the request to create the needed |VM|'s on |Rackspace| is to be authenticated against the desired |Rackspace| credentials which, depending on the interacion model, although not important for this scenario or the credential service, could belong to either the |EU| or the |SPECS| platform owner.

Technically during the |SLA| implementation phase, there will be a component, part of the enforcement module, that will need to trigger the provisioning of the required |VM|'s, and following that, the their proper configuration. By looking at the |RackSpace| |API| reference |pafu| we know that the implementation component in question will need to first obtain the credentials (consisting of a user name and matching password); following with a call to a |Rackspace| service to obtain an authentication token; only after which it can continue with the actual provisioning requests, by passing along the obtained authentication token.

Security concerns

Functionally there is no issue with the above workflow, except the concerns related to proper handling of the |Rackspace| credentials (i.e. the user name and password).

The first issues that are to be tackled are related to the conveying of those raw credentials, from either the |EU| or a specialized |SPECS| component, to the implementation component that has to use them. This includes mutual authentication between the two parties, and the credential data exchange through a secure channel.

However once these credentials are passed over to the implementation module, all control over their usage relies solely on the correct implementation and behaviour of that delegated module, which could use those credentials for any other purpose, for as long as the credentials are valid (usually a matter of months on end).

Therefore the |EU| is exposed to quite a few major risks, including improper credential usage, or even worse leakage to other parties, all of which could have, besides business disruption, also monetary losses.

Proposed solution

Unfortunately not much can be done to obtain proper security in absolute terms, which includes restricting the credential usage only for the purpose of |VM| creation and nothing else. This impossibility stems due to the way the |Rackspace| security model has been designed, namely once authenticated, the obtained token can be used for any purposes until it either expires (a matter of days) or it is explicitly revoked.

However |SPECS|, through the introduction of the credential service, could at least reduce the time frame in which the authentication token can be used for other purposes.

The solution is quite straight forward and implies running half the |Rackspace| authentication process by the credential service, and only the other half delegated to the implementation component.

Specifically, the credential service which holds the |Rackspace| credentials, will upon being requested by the implementation module, authenticate to |Rackspace| and obtain the needed authentication token, passing it in response to the implementation module, which in turn will use it to provision the required VM's for the secure web container deployment. However at the same time the credential service sets a timer on the obtained token, on whose triggering will revoke the authentication token, thus rendering it unusable after revocation.

Needless to say that the interactions between the credential service and the implementation module are themselves authenticated and secured, just like between any two |SPECS| components, possibly by the usage of the |SPECS| security tokens service for authentication (and possibly also for authorization), and TLS for confidentiality.

Discussion

Thus, like previously described, the proposed credential service can not solve the issue of leakage of the authentication token by the implementation module, but it can instead reduce the time frame during which an attack might successfully use it; nor does it solve the issue of improper usage of the token for other operations than VM creation.

As noted these limitations are not the fault of the proposed solution, namely the credential service, but that of the shortcomings of the |Rackspace| authentication scheme.

Overview

A second scenario where we highlight the potential usage of the proposed credential service, is that when the |EU| has signed an |SLA|, which at implementation requires the provisioning of a secure storage module that will allow the |EU| (or a delegated party) to securely store data on |S3|.

For this scenario the security module consists of a service which is handed the encrypted data to be stored on |S3| on behalf of the |EU|. Technically this implies that the storage service will require to gain access to the |EU| |AWS| credentials consisting of an access key (similar to an user name) and secret key (similar to a password) that are to be used each time a request is to be made to |S3| on behalf of the |EU|.

By looking at the |Amazon| |API| reference |yixe| we observe that, unlike |Rackspace|'s authentication scheme, the storage service needs for each individual request the actual |AWS| credentials, which are cryptographically combined with the request data to uniquely authenticate each individual request.

Security concerns

Just like in the previous scenario, the main issues are related to conveying the credential data, and the lack of control over their usage, therefore no other discussion is required, all the previous observations applying.

It must however be granted that |Amazon| does provide quite extensive access control policies which could limit the actions that can be carried with a certain set of credentials. However the usage of such policies are quite involving, requiring the switch to |IAM|, proper policy creation and enforcement, and proper credential life-cycle.

Therefore although it is practically possible to limit the allowed operations for a given set of credentials, like only being able to read and write in a given |S3| bucket, this however limits only the types of operations that can be done with a potential leaked set of credentials, and not the time frame during which an attack is possible.

Moreover the type of operations, an the target resources, are quite coarse, and in some scenarios, like possibly the secure storage, there might be a need for a more fine-grained approach.

Proposed solution

Just like in the case of |Rackspace| our proposal is to delegate the actual authentication procedure to the credential service, meanwhile leaving the actual enactment of the request to the implementation module (in this case the secure storage service).

Although at a first glance there is even less that can be done by the credential service, because according to the |Amazon| |API| reference |yixe| the actual credentials are needed for each individual request, therefore once exposed to the implementation service, they can't be "taken" back. (One could revoke the actual credentials, but this is not an operation to be done time and time again.)

However on closer inspection of the mentioned |API|, we can observe that the credential service could have an even greater role in how the credentials are used. The solution requires the implementation service to execute the first half of the authentication procedure by computing all the required fingerprints of the request meta-data and data, and passing this along to the credential service with other information identifying the requested operation (like the region, operation, resource, etc.). Then based on this partial data uniquely identifying the each request, the credential service can complete the authentication process by cryptographically combining the partial data with the actual credentials, obtaining the authenticating signature unique to the request in question, which then can be passed back to the implementation service.

Discussion

As described above, the proposed solution not only completely eliminates the need for the implementation module to have access to the |AWS| credentials, but allows the credential service to impose further restrictions on their usage, which possibly are not provided by the generic |AWS| policies.

Furthermore if the implementation service does leak the obtained authenticating signature, it is useless to an attacker because they can only be used to authenticate an identical operation to the signed one (thus in the worst case the same operation is executed twice), and furthermore the authentication token has only a time-window of about 30 seconds.