Re: [Teep] [ietf-teep/OTrP] HTTP Bindings (#14)

[Anders Rundgren <[e-mail]>]

Maybe there are actually multiple and quite different cloud use cases?

1. The one I mentioned is when the cloud account admin (user side) in some way have obtained a TA which they want to host at the cloud SP (push/upload).
2. If the cloud SP rather is a one-stop shop there is probably no need for a protocol.  The cloud SP would at the customer's request install a designated TA using a method specified by the cloud OS.
3. If the cloud SP relies on external TA vendors, they could use the client (pull/download) protocol variant alternatively simply fetching an image.

Does this sound reasonable?

https://tools.ietf.org/html/draft-thaler-teep-otrp-over-http-01

   "To be secure against malware, an OTrP implementation (referred to as
    an OTrP "Agent" on the client side, and a "Trusted Application
    Manager (TAM)" on the server side) must themselves run inside a TEE"

With respect to the client side, I don't believe this an absolute truth, it is rather a consequence of the TEEP architecture:
https://github.com/ietf-teep/architecture/issues/52
Well, of course some parts MUST run inside the TEE, but they can be considerably reduced in size and complexity as well a becoming more powerful.

Anders

On 2019-03-30 07:10, Anders Rundgren wrote:
> A shorter way of expressing the differences is that a mobile phone scenario is a TA pull/download scheme while a cloud scenario seems more like a TA push/upload thing.
>
> Anders
>
> On 2019-03-29 10:37, Anders Rundgren wrote:
>> On 2019-03-29 08:45, Dave Thaler wrote:
>>>
>>> I would suggest we should keep issue discussion on the list, and just use the github comments to summarize.
>>>
>>
>> Fine with me.
>>
>>> Comments below as an individual participant:
>>>
>>> *From:*Anders Rundgren <[e-mail]>
>>> *Sent:* Friday, March 29, 2019 8:12 AM
>>> *To:* ietf-teep/OTrP <[e-mail]>
>>> *Cc:* Subscribed <[e-mail]>
>>> *Subject:* [ietf-teep/OTrP] HTTP Bindings (#14)
>>>
>>> It seems that cloud based TEEs and client based TEEs would work differently (protocol wise) during provisioning, at least when HTTP is used as transport.
>>>
>>> *Client based TEE*:
>>> Request is coming from the client side (outbound) which means that the TAM request data must be delivered in a HTTP /response body/ while the TEE response is delivered in a subsequent HTTP POST request.
>>>
>>> Correct.
>>>
>>> *Cloud based TEE*:
>>> Request is coming from an outside service in the from of an HTTP POST request while the TEE response is returned in the associated HTTP response body.
>>>
>>> That’s not how it’s defined right now, it’s defined to work the same as the client based TEE summary above.
>>>
>>
>> I'm aware of that which was the reason for filing this issue.
>>
>>> This means that the TAM only needs to support one transport protocol mechanism, not two.
>>> It also allows the timing to be TEE-driven, i.e., when the TEE actually needs to do attestation or remediation, etc.
>>>
>>> Do you have any reason it **needs** to be different? I’m not currently aware of one, so prefer simplicity of one mechanism instead of two.
>>>
>>
>> Well, the traditional way of implementing cloud services over HTTP is client-service-to-cloud-service.  I haven't looked into this https://docs.microsoft.com/en-us/azure/key-vault/ <https://docs.microsoft.com/en-us/azure/key-vault/quick-create-cli> but I would be surprised if it doesn't work approximately as I described.  If the communication also needs to be asynchronous (highly unlikely), more substantial changes would be needed.
>>
>> The TEE provisioning API would (hopefully...) not change by offering two variants of HTTP bindings.
>>
>>> Another difference is that in a cloud based scenario, the requester (TAM) must also be authenticated as a legitimate cloud service account user. This is a part of an HTTP binding scheme as well.
>>>
>>> In both cases the TEE needs to authenticate the TAM, so I don’t think this is a difference either.
>>>
>>
>> I thought the TEE rather attested its identity etc. to the TAM. In a client scenario (like provisioning mobile phone TAs) the user authenticates to an "App Store" which in turn presumably provides whatever is needed for TAM access.
>>
>> In a cloud scenario like for a hosted Certificate Authority it is not obvious that there actually is a regular TAM.  Where is it and what would it do?
>>
>> Cheers,
>> Anders
>>
>>> Dave
>>>
>>>
>>> _______________________________________________
>>> TEEP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/teep
>>
>