Re: [Rats] freshness in the background check interaction model

Dave Thaler <dthaler@microsoft.com> Thu, 29 July 2021 17:28 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8195C3A1079; Thu, 29 Jul 2021 10:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level:
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] 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 vzyVOtEUPfx4; Thu, 29 Jul 2021 10:28:11 -0700 (PDT)
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2138.outbound.protection.outlook.com [40.107.101.138]) (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 AEBDD3A1066; Thu, 29 Jul 2021 10:28:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B+1JoFR9fv6y++q2kDaEVqp8j+Ph5Zz8CoHcspaLNSZeWfJwVTt0QntY4t0GYgjDmlR1RN0XEowNHvT12IhXyk7jJEBB/7vBoDgFih8ni0Z8PGreHKOrdKXQR0uQaeKfTDwVoqo2hrCqqp4cIzC+20F3JygJE0+f+Nka3e5VMQxI2vhOY83cxf1ZttpO6wI1qfJFWm6F85tGIIEXw+OEHz4Pv+hNkFkhs7Qw/6olKY4wHV9RtfeBAKr1t0dN6rwYQJ5b15OBAxxwsX/B0sV8nSLGK4OiDG3Ms+W4F3ghDJsLyuj5uqZJw5hCIcmTB2d4E6L9rTT/iPHQt/Ea6GM9zA==
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=J+Us/X2JQYmm3Ct9Kgoh4qx7BqoDhwWZCBW6V+2+wWI=; b=md8K6nlc5py01w/llInj7X4F3vFKPtaisiN5I7eJagwyiAKpaQjKrdwswUxOjOMDvi+Myz+gunzO272BGQI8Y83hmg6Ni4O37glZ5upgeKXDu/l8TNGLfe8ZoXX1mVoUX9eS0PtXQKHv4BTYOh3kS6V7dZB1z5Q7UVNbFAnIAKmP/MeS3Td/xPzqDqD37I7rUFd06iGCswNCbv7QauAxsbzl3OA/tR93ecPH6u9S5GODuq/kXMhmsXY+H6WarxYPZUuBqA4OmZxanGlVuW0g9GBd3FbWqcbMwXVkxRhEd6WlQUQ3tXYcJUoSFih1Ov5b94MtYfsrsbaXaFtGwkvUZw==
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=J+Us/X2JQYmm3Ct9Kgoh4qx7BqoDhwWZCBW6V+2+wWI=; b=EdO3kkOkOdKq/3QeoiFl1n2KxtrBabI9qVXC8G0KHWGEKZJULXrsKJwSQ4MNTxXbkzTnNnc9iEVTmncl2c3YiHL+6q5sPO63M9g9zQFo/cEupwm5CXiNRkRchSXUsU9oyf+hoe/CpJow5vHlhB7zB4ZX72xUpGV6hM8XGb7NQu8=
Received: from MW2PR2101MB0938.namprd21.prod.outlook.com (2603:10b6:302:4::11) by MW2PR2101MB1097.namprd21.prod.outlook.com (2603:10b6:302:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.8; Thu, 29 Jul 2021 17:28:09 +0000
Received: from MW2PR2101MB0938.namprd21.prod.outlook.com ([fe80::78:5f91:a03e:d89b]) by MW2PR2101MB0938.namprd21.prod.outlook.com ([fe80::78:5f91:a03e:d89b%6]) with mapi id 15.20.4394.012; Thu, 29 Jul 2021 17:28:09 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Michael Richardson <mcr@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Rats] freshness in the background check interaction model
Thread-Index: AQHXhBKp+FLqKLillU60oUNAZYxNeKtaNaXA
Date: Thu, 29 Jul 2021 17:28:09 +0000
Message-ID: <MW2PR2101MB09389222E1B785B74599567BA3EB9@MW2PR2101MB0938.namprd21.prod.outlook.com>
References: <19612.1627519296@localhost>
In-Reply-To: <19612.1627519296@localhost>
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_ActionId=c2c98a1b-7a4b-40e7-9606-a6b97d69c741; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2021-07-29T17:26:41Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3c6682f9-ae62-466f-aaa7-08d952b63bfa
x-ms-traffictypediagnostic: MW2PR2101MB1097:
x-microsoft-antispam-prvs: <MW2PR2101MB10979968796B6BA027DAE670A3EB9@MW2PR2101MB1097.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: shLaS5xbiK9JBPVdiqNxpcD1lSw8tXJjMhrXJxaFLPoZjklQlOzBKAJgh8uP83P4smx1mRjrhNXgwK9dGIIn0Pk/4jv8a0jGd6yYjflMv4kdz06+Un7GC0pAGJWgGS1WYxuhHdzeI3Xai71bKiCBe2UrIcTvyxZO8n03e1EQKuCCjHEGrogYjbhJSMKellhVbkk9HqCCSrNMdcG/BNMJVkzE4MqScY1/ITCYgpeuqsE94OGGtXlSVXXiF0Jt7IsjrB638vPtAb9tNflteOzWFTDYdreXS9wwDt4NDr5zRkpWYDycRmwLOWbGFDrJKOdtwvImNk06/JLqtvSWCzk0jdtXDEMjzR4KHB3tYC4HDeCvDFvT1YrjCQQw61A0VFLrKvInVt6BmNqVvjrxrwYdnXCYZ4bfEKFYiBrOWBlrr1Wc+SDtDCieMS5i67++A+zxRNJZZlYMn1couXG04prrw6iDObxCeoEXVBlPbFCKcMqkjDG+uG3E3AdIjzhb9oUKCOX7sPiXXSwnrpY/pfijNCJ4SNZtyJZF753+6BmZtk+cEmny/nrd/ZUkmIdv9vY7HVSjL3ETcFLJWprOhueIPAT7sDmJJdc8DXAcGVlvLKsdAqNQ/6fUSTpw2YYMrEPc+PxcQGRzYGvIiFKwgEnwZIps7m++SIzg7/JX6nWSRMd76iAdOGBtKJx7ceEGms6bldB8zO0QEFGna4vxzNVl0FWf7puf3uiovrvTwmy0SghzEnOdrxhnk+az1MmIXmWveQYrHdeN+4DA0Mq234qCAAvE9y29NO6fTedmmOhrAf+JyLWd3GyqiSXi+s0RbeyhE4M4XZgjajyWixpUmo5zAQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR2101MB0938.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8990500004)(122000001)(10290500003)(186003)(52536014)(55016002)(508600001)(9686003)(38100700002)(4326008)(8676002)(82950400001)(66476007)(82960400001)(110136005)(66556008)(2906002)(64756008)(966005)(66946007)(7696005)(26005)(66446008)(86362001)(76116006)(38070700005)(83380400001)(316002)(33656002)(71200400001)(8936002)(5660300002)(6506007)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zytaLOleNnpPaeFbC8o6Gwp+P/v8qzvdMTWAlSKBMhsIsfuuFUMjNx28D5n7ZqJsIIyZzm79pCNUpPJYv8CjvLYiqvYsCBbXSUG03kgB3UjItILqPxQKxwor6PF5+ahvup8v6IXIVlKgI4E2bX9/C3h4/xpb68zDFSe+uEPwOpLLEBTrVnWH2g4VCuMDqyRQD8e7OWCeXWNaxBGwGybTzB4a4IfLLlwkRVA5ZLsNQ4SHzx9zqyzIVBtPr77CFoKBUZSTZ8cYpH7nDi5NhotfmBJsVl+FOH8q07BYZANyjXsIJhjGp0YVOkEBvcpEtyf1I5YeM2CJLqVErJiEqZKXbdAgFJE74OShM1D8zpDKWdFMRgRO63eBS+yn4oCP5QvHJop3t9VkUOfve7YbdoWNbv/VXs6nhwcP5sB3sp6FiPfhXqm5cpqm8Xhqt2p1/k4V8ovdy9dfYSkX6uNSd06hovxntSgpAVUW8hsA96Xqhvv1pzDzEz3legFCRjzgdDwGeSIbCQ3oepOHa17tomzaUfTZ9TZWPMQxQBemheoOngKS+RJKJIgntfhJ1tu896jdNH9HwudBsbXLZlv8rPB4OItnhfz8TPCKro/T01afd7iROSVpwsFx6jJzFn4hOj8uMWmWOAj29fw9BvDQZEnfItRcsOiEtMdrHYcVz/tyAjeUK96e01Acwnq/mAopxW0L7GpujKpR2rdocYo6Qlb1ceFBk5aRAmlJh+Fk/SVgxrkyRsfVjkmTq+z57r2DYWLOB93ntbUlfGhZeabBVlh71fulTvOea3LqBg7R/2aXBHzRo7AG0JcPuMpKIfNFlBWMsFSW5ZpxdLWT50qTgBP6dM4XJg1gdmZ6Q445L/y21fc3raippGwwcV5S9IopDxoiCRzCWg6nFj/WZqeB25gdq0DHNTZ6EPgqkwoznbEOvMmkd7j8ngUtsdRh1n/wQZhOTYaJcchf0DaT9lVe7farTTgcAuMAMOQB04nq351mtK18HarNUUK1KyvL2Grg43XfRGXhC/kEJS5pM7DFlR9x/GHiNyQnxfGpm4UuC3MCzLyCwMjDXmGggu8GgKFbaN+ZjSvlqN3eeAJo9k84emiSkfir+xVcbDlQ1izgwsuolgdySQHvuV2hOyehoilZk8eJTypDKGHPIbx50W/P9kF1oI2OzXQrTi/Rx18dIezrjYTkgs+ECQjBTok2xV/sxjPfmoHCBRqf8oCAYzwJQNqMqIiKntMdMlD8TBkqzhoUH8mXqK40x6gHJHW42fRzyTId0ecFfmYKCMMpUawqgaYpslNaE9vHNjHetIrID/DbO0nYvmE3oNQGAV8vW4XSqxXj
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW2PR2101MB0938.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c6682f9-ae62-466f-aaa7-08d952b63bfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2021 17:28:09.2315 (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: fT8r3O3Ji0yYQCEhRpQFljAudMo50JkR+0LqQvziRcWRv+BioAbEXHLuENCgLpJ/qKv4HPJXQc6WsK49Bm4nS0p4HqoEjuyu06NGzz5es40=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1097
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/d5ijvJx7ZSR8GcvNmTWfBGwSuK8>
Subject: Re: [Rats] freshness in the background check interaction model
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 17:28:17 -0000

To answer the question about TEEP, the example in
https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.5
is indeed the default (i.e., when using nonces instead of timestamps or epoch ids)
case that TEEP uses for freshness.

TEEP can also negotiate use of timestamps (in which case
https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-16.4 applies)
or epoch ids, if both sides support them.

Dave

-----Original Message-----
From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Wednesday, July 28, 2021 5:42 PM
To: rats@ietf.org
Cc: anima@ietf.org
Subject: [Rats] freshness in the background check interaction model


In the background check interaction we assume that the Attester has connectivity to the Relying Party, and that Relying Party will communicate with a Verifier itself, passing Evidence along the way.

{This is not an architectural issue.  This is an issue of how to implement RATS in a particular flow}

This could occur as part of Network Endpoint Assessment, including both 802.1X processes or onboarding such as with BRSKI (RFC8995).
(I am unclear in the TEEP case (which uses both interaction models), how this
works)

In the BRSKI case the mapping is as follows:

1) Pledge    => Attester.
2) Registrar => Relying Party.
3) MASA      => Verifier

This works well, because the MASA is associated with the manufacturer and so it can get all the Endorsements or Reference Values by private channel.

The Pledge reaches out to the Registrar, and provides it with a Voucher-Request.
We could trivially include Evidence (or pretty much any form) in the Voucher-Request.

The Voucher could include a reply which can be evaluated by the Registrar (Relying Party) to provide a signal to the Registrar (they RP) as to whether or not the Pledge (Attester)'s evidence is satisfactory.

There are some options other than embedded the answer for the (2)->(3) protocol including:
  a) use another end-point on the (3) that would return the response.
  b) use multipart/mixed reply for the reply from (3)->(2)
     [this wins for constrained case, because (1) never needs to see this]

but, the purpose of this email is to ask about how we get freshness.

Ideally, a nonce would be created by the Verifier (MASA) and transmitted to the Attester (Pledge) via the RP (Registrar).  A challenge is that the Registrar doesn't know which MASA to use until after it has received some communication from the Pledge.  That comes with the Pledge's IDevID, which it uses both to sign the Voucher-Request, and which it uses as TLS Client Certificate.

Since the TLS setup occurs before the Voucher-Request, in theory the Registrar could retrieve a nonce from the Verifier, but in the BRSKI protocol flow, we did not add a step to return the Nonce to the Pledge.

In the middle of writing this, a gather.town discussion occured...

A suggestion was to use a TLS Exporter to get a nonce that both the Registrar and the Pledge knew.  The Pledge can then build it's Evidence and include
that in the (raw) Voucher-Request.   The Registrar then has to communicate this to
the MASA (Verifier)..... how do this is a question... probably in the parboiled Voucher-request.

In the middle of this, Goran Selander brought out his slides on draft-selander-ace-ake-authz, and most of this can be wrapped up into EDHOC.
If we can get our packets small enough, we can do AKE, Enrollment, and Remote Attestation in three flights (two round trips).

Is it acceptable for a nonce to be created via TLS Exporter?
Is it acceptable for the nonce to be known to the RP?
Is it okay that the Verifier didn't get to insert entropy into the nonce?

All of this coming to a draft near you.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C4dbc5796d82a44c6466308d95229af30%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637631161721316112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=mK8Jyrn0N7pehFvHxgJBDAL0p3%2FxjWcBi13Vbrv%2Fy2Q%3D&amp;reserved=0        |   ruby on rails    [