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

From: Dave Thaler <[email-masked]>
Date: Fri, 29 Mar 2019 07:45:56 +0000

I would suggest we should keep issue discussion on the list, and just use the github comments to summarize.

Comments below as an individual participant:

From: Anders Rundgren <[email-masked]>
Sent: Friday, March 29, 2019 8:12 AM
To: ietf-teep/OTrP <[email-masked]>
Cc: Subscribed <[email-masked]>
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.
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.

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.

Dave

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Mar 2019 10:37:22 +0100

> I would suggest we should keep issue discussion on the list, and just use the github comments to summarize.

Fine with me.

> *From:*Anders Rundgren <[email-masked]>
> *Sent:* Friday, March 29, 2019 8:12 AM
> *To:* ietf-teep/OTrP <[email-masked]>
> *Cc:* Subscribed <[email-masked]>
> *Subject:* [ietf-teep/OTrP] HTTP Bindings (#14)
>
> *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*:

I'm aware of that which was the reason for filing this issue.

> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 30 Mar 2019 07:10:51 +0100

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