[Teep] What goes in claims vs TEEP protocol fields

Dave Thaler <dthaler@microsoft.com> Fri, 16 October 2020 21:37 UTC

Return-Path: <dthaler@microsoft.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 8C29F3A0B5D for <teep@ietfa.amsl.com>; Fri, 16 Oct 2020 14:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level:
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 cE-gRqaqi1kG for <teep@ietfa.amsl.com>; Fri, 16 Oct 2020 14:37:23 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2130.outbound.protection.outlook.com [40.107.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63D23A0B59 for <teep@ietf.org>; Fri, 16 Oct 2020 14:37:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sthpn1PXHiif30Lh6+DQG6kqbyTtM3yL8Lc+ziFHRSzNRGflY04tXePjPwPfTFoJ6xOdwA5FJKah/XFVfLo83cRgcPC6A+WcO2ZEJnWQv8HAA2y/zZEKvJQuLgrQ2RFfVysdviTnpn1ipvrk0wxfLLgF4lISHwAncdKnG58R+ZFwZq0CG+9Mtye4r0V75AoGo1sJ/+ElFXpnj2XOlIq4Ph+g4N6kQbPdkoVuNnfcpl2WN29haE9AMdppHwH2oTdoH9blXKK75pX/LAyahdLk3hWQtGtzQdDFOB7M83iZ0kEZlPqD4r0PlL0bm2jydfLnoVEjmVrQRmQzlmdTKTTzew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LCB6PrW0O4O1yfo1EMnpVZfdFqqNFibiyqFPiob96mg=; b=JaZSotcRghSNIfB3BgdECPj3iUjDTFbwMoxldg21pmkz0uONXIzxFckxyQ2rB4Zua55mWTnLrELCYeVMWzpuv6WB00TF6mJdbUfNJPVGGZ6CMBpmpN/cZYcMAmMnaUN9uQX3X8Y0Ce6Kehdw/BBsyUdGkVuw1aFT5LBz1kI1y3iYCjYBUIL0GYMyiirW1qnaHidC+iB4UAcjlrX9W/hedwY6+D904RCOvs2xU2TUTPwIqynBbyeuK9jylNmVapUsf7UtTd7apRymtofrvdDW3c3cwlDDFrc5AO14fjWNSQUI3TpE63+fhOuEXkh6XvuoLQAwhoO1XgpZn3i0ZsU+ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LCB6PrW0O4O1yfo1EMnpVZfdFqqNFibiyqFPiob96mg=; b=SZz3Sqo9NB1RW+oymQIaM/rGqZj0we4UJfeAcIY2kxTTa2GJ96mu00Rk+DkNX/xKEgcFahN0NPC3MGMjBK2SHRQ1pKad1ZoqvtTJWhvjjR1/Ko45T2/Xgy7bVXmyforiGSgSutYSAPReC2oI7/mVcqCz0nLKfdspQ38DP+FTF1g=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1346.namprd21.prod.outlook.com (2603:10b6:208:92::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.3; Fri, 16 Oct 2020 21:37:21 +0000
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::8a3:4e58:a8ed:8193]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::8a3:4e58:a8ed:8193%6]) with mapi id 15.20.3477.014; Fri, 16 Oct 2020 21:37:21 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: teep <teep@ietf.org>
Thread-Topic: What goes in claims vs TEEP protocol fields
Thread-Index: AdakBHDdce9UENQ+SbCc5deK37lj8g==
Date: Fri, 16 Oct 2020 21:37:21 +0000
Message-ID: <BL0PR2101MB1027B60274595C0D7C63AA4EA3030@BL0PR2101MB1027.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-16T21:37:19Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5da4b9e2-a5df-4875-8f9d-0dc3ffe3b5d6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2601:600:9780:8d0:9127:b5fa:9b25:d08]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8a46b3d7-5095-4086-2203-08d8721baa2b
x-ms-traffictypediagnostic: BL0PR2101MB1346:
x-microsoft-antispam-prvs: <BL0PR2101MB13469F2CEDE86528BCA8A70BA3030@BL0PR2101MB1346.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: B152HrpfTAlokc4nInUE0uWaaRwFcrvcVHuR4QjaUGeh9ZC7vsuK0J30PcgJvdD43szQ4AvxS5o8a7xAtVApO/HiLGBAQtmqULOluZ+32fv6Cp1JUoosdzoQUdXVLjhIhW6JqyJyQUu0z8X3s3QbWDBh3vlmq0qhZAFBpLMSDmdnal4/WePkal0UOQ1+UCG/YUHzbxVkaysJAVKF7eBAuMO7Ey2FjAfb5RrlwtUWowNz6lOb+075ozy5Y4QI0MLfY6+tCrdf+dBLqZrI8FJMbyETxlO+eeXiF6yJhtzDtSarp9w11/VSz3Okb6nAP4r5InoujBvKgem+CHGlEOqMqIUIyzfU8zz0GDXXYvo/PtOxjRuOPDhxXtMr0hEugH6Pci7TJSGT1yLNYGu4+tv8UA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(166002)(5660300002)(186003)(2906002)(55016002)(8936002)(83380400001)(6506007)(316002)(8676002)(6916009)(66476007)(66556008)(76116006)(478600001)(71200400001)(52536014)(10290500003)(66446008)(66946007)(64756008)(33656002)(86362001)(82950400001)(8990500004)(7696005)(9686003)(82960400001)(966005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 2t2L0aHZXa1UZPsbi33Nxy8Z5LHJW8MybCSFH5qoO/EtYI3m8XOqE89y/2zCak/b1FOgBW984fwjfvdQmxV69LW/J1w0ddBxQBuYg0MYV3PRoIYr07lYPj6iWV0JBuyRcLMdP/6VRpvuEppa3H8EPQJQ4JHlyQqbUnVuXj41rD5VnU5KxO6f1EA398/v/kk5S4u4ZHra4wng54WmcSeMqEPDMmB0yEOTjWXSAu+54sUE311BBuQzU59lBYcbZZWP0Yw13MCnffKR6nnamfIoKJH9T7AHFk6digJtgkltqxOmN+1CU0X+bPKkHHwjHLiRGNV1FWBMGGeGQ1tGsT3ro5YiamPd9jZctOPPHdXar/I/o7qSsVKleO9ef8qo0+xECzteg2nq2SCm7WsI19MgvWXLtOo8Tqw1YXvcREJP2+BeHyrTjhz9PQ3kFdbglTofyybqQ9ZJYLrYPBUehBQYNXPOzNv6NICmUSZoN4HoQhmyLKcQA1bh52QZE6Y1AeJMs1vWnRjcm4AxaAl5mT62COPTmbECaMn1ku7QGfrd2OZwWMwgYEDrklKjoBOuq1WmBcZaiQukYoHjAFImyu2RhbMytXgcbHyUnL9DJ+htRS+A8ewO9bLqoVw/Jn2+3aofcTLmWA0S6qBZxK17Msj8akjRni6dmjq8sJZss3DaApLcsVSaqqB45Ku1ErmhkjD79MTo8TbT8LfBF13vhMpcVA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027B60274595C0D7C63AA4EA3030BL0PR2101MB1027_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a46b3d7-5095-4086-2203-08d8721baa2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 21:37:21.6332 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ns7FZZJk3ih17GgBUnsDxEnnd7lX8jJ/m+cm3WKeqluYzapHHk543r+7MRm+wFyYLkxBXWySMFLQ8kbZ+QwTTBeJwjfC3MOAtnNrTKifgsA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1346
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/WTPQrvwVSMAKOHepjc24JW9jonM>
Subject: [Teep] What goes in claims vs TEEP protocol fields
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, 16 Oct 2020 21:37:26 -0000

At IETF 108 I led a discussion about these, for which the minutes summarize:

#5 ...when have TA binary but need metadata
    Issues with passing in information
    Options
        a) attestation claims (what the doc says now)
        b) separate QueryResponse field
If no objections, Dave suggests (a), as it does not require any change to the current architecture doc. (No comments in the chat or queue)

#16 List of no-longer needed TAs
    How to remove TA. Does a TAM know that there are no apps calling in to a TA anymore. Should we support passing a list of TA that are no longer needed since only the TAM is able to clean up no longer needed TAs. Dave proposes (a) which is a change to the arch document, doing it via an attestations claims.

Options to support this scenario:
        a) attestation claims
        b) separate QueryResponse field
        c) do not support

No one objected to moving forward with (a): Hannes Tschoefenig, Russ Housley, Akira Tsukamoto and 大居 司 (Tsukasa Oi) indicated support.

Since there were “no comments in the chat or queue” as noted, the consensus was simply based on there being no
objection to my own proposal, which in turn was simply based on minimizing doc changes.  That decision was not based on
any real technical consideration. Now I believe there is a strong technical reason to go with (b) for both, and so I am proposing
changing to (b) in both the architecture and the protocol doc.  In the arch doc, this simply involves removal of text.   The
protocol doc doesn’t yet say (a) or (b) so needs changes either way but https://github.com/ietf-teep/teep-protocol/pull/47 proposes (b).

Rationale:
A new technical concern with (a) was raised based on the following text in section 8 of the arch draft:
In addition to the use of cryptographic algorithms in TEEP, there is
also the need to make use of different attestation technologies. A
device must provide techniques to inform a TAM about the attestation
technology it supports. For many deployment cases it is more likely
for the TAM to support one or more attestation techniques whereas the
device may only support one.

The concern is that:

1)     Requested components and Unneeded components are pieces of information that must be

consumed by the TAM (which is a Relying Party) rather than the Verifier, as shown in the

figure above the text we’re discussing.   Claims in evidence go to the Verifier not the TAM per se.

2)     AThe format and content of claims can vary by attestation technique (serialization format or protocol),

and such agility would require the protocol to be capable of supporting multiple techniques,

so just supporting such info in EAT claims alone is insufficient.

Thus, claims should be used for fields that are important to the Verifier, whereas
protocol fields should be used for information that is destined for the TAM and not important to the Verifier.

As such, I am generating text for both documents to change to (b) to adhere to the principle above.

Please speak up if you have any objections.

Dave