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

Anders Rundgren <anders.rundgren.net@gmail.com> Fri, 29 March 2019 09:37 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0212012B for <teep@ietfa.amsl.com>; Fri, 29 Mar 2019 02:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q4_x-YjtEAJ for <teep@ietfa.amsl.com>; Fri, 29 Mar 2019 02:37:30 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A8F12014C for <teep@ietf.org>; Fri, 29 Mar 2019 02:37:29 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id c1so621888wml.4 for <teep@ietf.org>; Fri, 29 Mar 2019 02:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=EOvSdFYqY+C30SvQGJhQxB/66OJxtoj5aacAULx9x5s=; b=FQTsCv8vQHUDpOTAAMMZkCkAnuJ/EN+Jpaj5AkWhqIWP9cDPLDWKRt57aM3emWKxXH vxBX5hGiX+ukDeyp978V2r9xm+XY9Si/VcZ0YjPTpTtLqUpi/ITiiO/4ExxWbPLb4PEt E3OR22fSCuImuQi+S+992C2BgiKfLBuKJbwiMDzRWIqar/Kdw3eGROnJHRfGvkocUcT/ OamcEa1+UsNdvqIKWe+HXRhscNxuGzvHnny6C2OZybGOu2NMhAcXrk6coGZ7qUzSOU4E s9LaNpMrZF3mI63zlwECRoLFvCoM3bPrCrEaIFBTdYjAVHm5jQs4e8ZFcYa95lu8ed18 9Quw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EOvSdFYqY+C30SvQGJhQxB/66OJxtoj5aacAULx9x5s=; b=ZsSm56qdVfeD4IryjmoDDBNnHecEvNzD7/WZxV5794fcEdmbgx+BE+s3TbP4m7h/V3 cvVQVonIKDdR+OixWOGCfHSTyVe76I28idEIUdH0yjgL3+aSvd8BXDWgL5Lkr25Luq7/ pIDrcdVvRs3WYt47DIYb0mt3kZ3CBtNtHzLjiszL6nCsNMlujBl3ZuNSrbmzzZmtD4/h Ni+PDGahTWHCzo+W4Aeqqy3IilGtnWVif2ChfdTUG06P4tVikV0xY1F6W74AfVCI5AMP kM5zeyhzyrAnUHDyC7drMl6NII5utc6j3Az1znqWcnZEpclbnbi9S1SHDWhWJT7ytOwG 1ubw==
X-Gm-Message-State: APjAAAVz9Nc2+zmo6q3F2BN93mHGHqxidEtYeJJUc2gFsQwLjU01e8NS xhH19BWNSeuV9h5q+B3TIjutkDHf8fw=
X-Google-Smtp-Source: APXvYqxF61M3YWOkw3QyvCqSjYOPqvAE/l93bMfXbsTadYQSAiWcAphRq1H7Mv6A+liEvVBzsD7WtQ==
X-Received: by 2002:a7b:c111:: with SMTP id w17mr3075692wmi.6.1553852247768; Fri, 29 Mar 2019 02:37:27 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b11sm1704573wru.61.2019.03.29.02.37.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 02:37:25 -0700 (PDT)
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, teep <teep@ietf.org>
References: <ietf-teep/OTrP/issues/14@github.com> <CY4PR21MB0168D9DB7A27245D2B5A354FA35A0@CY4PR21MB0168.namprd21.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <e361de94-f219-cee7-0aa4-45c3d14e2732@gmail.com>
Date: Fri, 29 Mar 2019 10:37:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0168D9DB7A27245D2B5A354FA35A0@CY4PR21MB0168.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------4EAE8E8A9A11F57E84D2614C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/k9K9fh9s-lseMtR922BzPxA0Q1g>
Subject: Re: [Teep] [ietf-teep/OTrP] HTTP Bindings (#14)
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 09:37:32 -0000

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