That is correct, the variety of versions, components and patches is the first thing that comes to everyone's mind with this approach. But the idea is not to have a trusted third party/CA that would be able to assess _all_ combinations. With both approaches, the 'assessment' is left out as a stub or "assumption" (whichever you prefer). In this case it doesn't actually matter who does the assessment - the IaaS provider or a CA, since the assessment criteria are the unsolved issue.
The use case we're examining here is when a certain IaaS provider is contracted to supply IaaS to a client with "special requirements", let's call it C. That would mean, e.g: 1. Potentially not all hosts would be used to deploy VMs for C 2. Potentially patches and versioning might go through a separate upgrade flow for those hosts To summarize and address your concerns here: * imo once a client is concerned enough to require "trusted hosts", the use of using external assessment case becomes valid (and assessment by the IaaS provider becomes useless) * wrt to variation of the software stack, the big issue is the assessment criteria rather than the assessing party. Cheers, /Nico. On 14 November 2012 04:27, Tian, Kevin <kevin.t...@intel.com> wrote: > I would see the major blocking issue on this:**** > > ** ** > > “However, imo an IaaS provider that claims to offer trusted hosts but > hesitates to reveal the software stack of it's hosts to an external auditor > (CA in this case) would have issues with credibility”**** > > ** ** > > every IaaS provide has its own software stack, picking different > components, with different versions, possibly adding different patches. The > stack can be changed frequently. Rackspace says they can publish a build in > less than 1hrs to deploy a new stack. Having an external CA to hold > credentials for such large uncertain combos is almost a mission impossible. > J**** > > ** ** > > Thanks**** > > Kevin**** > > ** ** > > ** ** > > *From:* Nicolae Paladi [mailto:n.pal...@gmail.com] > *Sent:* Tuesday, November 13, 2012 11:46 PM > *To:* Dugger, Donald D > *Cc:* openstack; Tian, Kevin; Li, Susie; Wei, Gang; Maliszewski, Richard L > > *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack**** > > ** ** > > Hi, **** > > ** ** > > I agree that the use case of a trusted IaaS provider (with possibly > compromised nodes) is a valid one and should have support in the openstack > codebase, although it seems rather dicey to trust the IaaS provider which > does not trust it's own hosts.**** > > And your understanding is correct, the idea is to add a 3rd party 'CA' > with the aim to assess the integrity of the hosts based on the data > produced by the TPM.**** > > ** ** > > What I am advocating here is the scenario where the IaaS can not be > trusted. **** > > In this case the CA would only gain information about the software stack > of the IaaS provider's hosts, necessary to perform the attestation. > However, imo an IaaS provider that claims to offer trusted hosts but > hesitates to reveal the software stack of it's hosts to an external auditor > (CA in this case) would have issues with credibility.**** > > ** ** > > Wrt complexity, this would require:**** > > ** ** > > * sending the attestation information externally to the 'CA' and taking a > launch/not launch decision based on the result of the attestation. Even if > the untrusted IaaS launches the VM, the client can easily detect the fraud. > **** > > ** ** > > * on the compute host, decrypting the nonce provided by the client (and > _sealed_ by the CA to the trusted configuration of the host). That will add > up to the codebase but is rather trivial (involves mostly interacting with > the TPM).**** > > ** ** > > Now, there are some design choices to be made, e.g. whether the host > communicates its attestation credentials directly to the CA in an https > session or the scheduler does that. However, it does not change the > important point that the client can verify that the VM was started on a > trusted host, without having to rely on the IaaS provider.**** > > ** ** > > A common topic to both models (trusted or untrusted IaaS provider) is the > question of "security profiles" for the hosts -- are you considering binary > values (trusted/untrusted) or some finer-grained scale?**** > > ** ** > > Happy to hear your opinions and continue the discussion;**** > > ** ** > > cheers, **** > > /Nico.**** > > ** ** > > ** ** > > On 12 November 2012 21:23, Dugger, Donald D <donald.d.dug...@intel.com> > wrote:**** > > Nicolae-**** > > **** > > We’ve been working under the assumption you have trust the IaaS provider > (individual nodes might have been compromised somehow but you trust the > provider itself). I think what you are looking at is adding a 3rd party > CA which is significantly increasing the complexity of the solution and > potentially exposing the IaaS’s infrastructure to a 3rd party, probably > not desirable to the IaaS provider.**** > > **** > > I’ve added some others to the thread who can chime in with their opinions. > **** > > **** > > --**** > > Don Dugger**** > > "Censeo Toto nos in Kansa esse decisse." - D. Gale**** > > Ph: 303/443-3786**** > > **** > > *From:* Nicolae Paladi [mailto:n.pal...@gmail.com] > *Sent:* Wednesday, November 07, 2012 7:42 AM > *To:* Dugger, Donald D > *Cc:* openstack > *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack**** > > **** > > Hi, **** > > **** > > so basically my questions/thoughts about support for TC in OpenStack are > based on a**** > > somewhat different attack model where the IaaS is actually not trusted.*** > * > > **** > > That is in contrast with the Trusted Compute Pools, where the > scheduler/trusted_filter**** > > is assumed to reject the host as a candidate for running the VM if it does > not have a **** > > corresponding "trust value". However, nothing prevents a really evil IaaS > deployment**** > > to ignore this trust value and go ahead, launch the VM and return it to > the client. So**** > > there's an improvement suggestion focusing on that part.**** > > **** > > The model that I have in mind assumes both no trust in the IaaS > setup/provider.**** > > **** > > So the gist is that:**** > > **** > > 1. Client could upload a secret encrypted with the public key of the > authentication service **** > > (possible to include in the extra_specs)**** > > **** > > 2. The Attestation Service, after verifying the compute host could bind > the secret to the**** > > hosts trusted configuration, so that the host can inject the secret into > the VM**** > > **** > > With this approach, a malicious IaaS provider can still launch the VM on > an untrusted host, but**** > > now he client can verify that the VM has been started on a 'trusted' host. > **** > > **** > > So the questions around this are -- **** > > 1. Is the scenario of an untrusted IaaS deployment considered for Trusted > Compute Pools?**** > > **** > > 2. Is there any work ongoing to extend Trusted Compute Polls for storage > as well? Or otherwise**** > > put, what about the storage, is the solution to encrypt all data on the > compute host prior to**** > > storing it in the object store?**** > > **** > > 3. Is there any work ongoing on the evaluation side, namely the evaluation > of the trust attributes**** > > obtained from the host -- and do Trusted Compute Pools consider a binary > value (trusted/untrusted)**** > > or a scale of security profiles?**** > > **** > > Cheers, **** > > /Nico.**** > > **** > > **** > > On 6 November 2012 19:07, Dugger, Donald D <donald.d.dug...@intel.com> > wrote:**** > > Nico-**** > > **** > > This is the appropriate place for discussions about Trusted Compute Pools > under OpenStack. Feel free to send out any ideas you have, I know I and > others would be very interested in what you have.**** > > **** > > --**** > > Don Dugger**** > > "Censeo Toto nos in Kansa esse decisse." - D. Gale**** > > Ph: 303/443-3786**** > > **** > > *From:* > openstack-bounces+donald.d.dugger=intel....@lists.launchpad.net[mailto: > openstack-bounces+donald.d.dugger=intel....@lists.launchpad.net] *On > Behalf Of *Nicolae Paladi > *Sent:* Tuesday, November 06, 2012 8:35 AM > *To:* openstack > *Subject:* [Openstack] Plans for Trusted Computing in OpenStack**** > > **** > > Hi, **** > > **** > > I am involved in a project that aims to use TPM modules to ensure that**** > > the compute nodes run a 'trusted' software stack in a public IaaS > deployment.**** > > **** > > I've read about trusted computing pools ( > http://wiki.openstack.org/TrustedComputingPools)**** > > checked out the OpenAttestation project and seen a presentation from the > OpenStack**** > > summit (Putting Trust in > OpenStack<http://www.openstack.org/summit/san-diego-2012/openstack-summit-sessions/presentation/putting-trust-in-openstack>) > in order to get a better understading of where**** > > OpenStack is heading towards wrt TPM support.**** > > **** > > Are there any more resources, discussions, mailing lists that I could > check out and**** > > where I could potentially bounce ideas?**** > > **** > > Cheers, **** > > /Nico.**** > > **** > > ** ** >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
