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

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 <notifications@github.com>
>> *Sent:* Friday, March 29, 2019 8:12 AM
>> *To:* ietf-teep/OTrP <OTrP@noreply.github.com>
>> *Cc:* Subscribed <subscribed@noreply.github.com>
>> *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
>> TEEP@ietf.org
>> https://www.ietf.org/mailman/listinfo/teep
>