Re: [Rats] Out-of-band key material set up in architecture document

Guy Fedorkow <gfedorkow@juniper.net> Wed, 06 November 2019 18:53 UTC

Return-Path: <gfedorkow@juniper.net>
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 619B4120145 for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 10:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=ddgP3d8P; dkim=pass (1024-bit key) header.d=juniper.net header.b=LcuqMT/1
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 RzQ65Hsrk91J for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 10:53:11 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A8C69120108 for <rats@ietf.org>; Wed, 6 Nov 2019 10:53:11 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA6Iq3W5024302; Wed, 6 Nov 2019 10:53:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=CYD3DHaHoD6NG4bZnPvx7KetqaRweO/KB1NxDMyr+qE=; b=ddgP3d8PvnwEEh1kY90OYGVOMzmypQSQxr1Mnq0bVKds1ElreDj6iyUGwQN0kFsKdvIJ iV4DYNm+LMg5v5NMe5pCAaVK/oRlalVrUnsZn5AH3/NSqakD7WE10YA2/BdR7FJXVyUl XlaXqkKPnRludZr20sub1S2+ydPp6zlTV4QKJsUYfE/KVevhusNkevXwZutGGac3an0n 4mtARXAtg75gZ9NsqIehAj6esLmUWPLCmpUE2KxSrkTXgYcvIB0lEvGksRCaJQaInwA0 L/X0iDOMNRqVTVS8ZWxhbnEJYF9uMQrG1UVkrRDH3uRLaG5S8DK2LTh59DMamo+Ww5nn Og==
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2059.outbound.protection.outlook.com [104.47.49.59]) by mx0b-00273201.pphosted.com with ESMTP id 2w41vjg80v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 10:53:07 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aZtJDx0mg1tdMtzOTCLHDNIQ8A8KD5iu2z4z0+8VoWoTpizfN6OHsTqlr8a2HxnDvraz2yQYQaB8vHb8VEHJpFM2DwNfUCAfqSQV0VTgzkgcj/e6F/fZIk11ZbFDlVrPx9/TetLR4Vqf7LK2XJzF7Vik5EWlXVvWab1ERwkTxa8fN3aymZS6qjcrL61hsn/CuwPG9c9pK3P3ko57iz3Q6U2THTkgXs8C4ff6hJwfElp4XuxxwrNN+DdwN8sO4lmrRHU1xB5taaj8SvC08ZqIAyLzlgY9Cg9ajH7Kaz1cyiIsATSgrfAK3PKQskX6rr6JQrgvwDXGUC4kurrB3OI2uQ==
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=CYD3DHaHoD6NG4bZnPvx7KetqaRweO/KB1NxDMyr+qE=; b=RhnFEmoHcwf8CXI8L1+5phIFNxlHCCLTf7LfxBfbRO864KoljwS/66ZH1df69V5TeYoPLYfQ0NxA/ERaO9NI7UdF0ILOeLcJJzSSS1n8QjWBfXQE+wnBUzGem+7gTUojwcCb0XD4WlIGMFTfOhOR6YUeTOp72htvyOIVN0skodiBV4lr49vaErrS1lD3UKkjHiAIVCPKk1VZaFXu9qx01MLlAYtzzHHvFkuv6uHBJd07egZSD6k5za1jKuFPIGWjm9jaWlIG89bWK7fdX2+cqhCVHot5O339UPVMax2E3FHD9t8hPTzdT8adk6q+7HfmTVE+SMigSgye3DbuhkMKRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CYD3DHaHoD6NG4bZnPvx7KetqaRweO/KB1NxDMyr+qE=; b=LcuqMT/1Hig4N6gg2C7xqiKjqnh5O5+EqH4sodnRVy9iItJ0UB4R+5uwzkBfD2AhLgqltFQa9Jj6b0JkBpCmWlXhVeDxxQLZjxTVnJbOq3KhUxGd8hIPPx3T3FE7LbrMDPGMiHApw4vWdYKkutfDIhohUpXGNWpuBr1ZNAaeZZk=
Received: from BYAPR05MB4248.namprd05.prod.outlook.com (20.176.251.147) by BYAPR05MB4966.namprd05.prod.outlook.com (20.177.229.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 18:53:04 +0000
Received: from BYAPR05MB4248.namprd05.prod.outlook.com ([fe80::dd02:9d00:19f6:b4e]) by BYAPR05MB4248.namprd05.prod.outlook.com ([fe80::dd02:9d00:19f6:b4e%6]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 18:53:04 +0000
From: Guy Fedorkow <gfedorkow@juniper.net>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Laurence Lundblade <lgl@island-resort.com>, Dave Thaler <dthaler@microsoft.com>
CC: "rats@ietf.org" <rats@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Thread-Topic: [Rats] Out-of-band key material set up in architecture document
Thread-Index: AQHVlBYHfaj0pPUV6EO1nm+V0K/T+qd9PMYAgAEh1gCAAARoAIAAGsGg
Content-Class:
Date: Wed, 6 Nov 2019 18:53:03 +0000
Message-ID: <BYAPR05MB42483C3F59DA5B99220B0E12BA790@BYAPR05MB4248.namprd05.prod.outlook.com>
References: <9B93F41C-3707-4822-B3F5-5F9978872786@island-resort.com> <MWHPR21MB0784D3762243B2D09E0E6DC8A37E0@MWHPR21MB0784.namprd21.prod.outlook.com> <5050A16A-68D3-4D6A-859F-EAFF74FAF096@island-resort.com> <c4977362-1bf5-7da3-3b62-e27d612f5d04@sit.fraunhofer.de>
In-Reply-To: <c4977362-1bf5-7da3-3b62-e27d612f5d04@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=gfedorkow@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-11-06T18:53:00.6019783Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=7b2b264b-b456-4f39-b7b4-01ce163a0180; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ac9d1081-f422-4225-5466-08d762ea8df9
x-ms-traffictypediagnostic: BYAPR05MB4966:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR05MB4966146CA596375C9466FCC3BA790@BYAPR05MB4966.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(136003)(376002)(346002)(189003)(13464003)(199004)(4326008)(110136005)(3846002)(52536014)(76116006)(71200400001)(71190400001)(9686003)(86362001)(66946007)(64756008)(6306002)(66476007)(66556008)(966005)(6246003)(66446008)(55016002)(66066001)(2906002)(14444005)(256004)(478600001)(6436002)(25786009)(186003)(7696005)(76176011)(316002)(33656002)(81166006)(81156014)(54906003)(99286004)(1511001)(11346002)(7736002)(5660300002)(74316002)(229853002)(102836004)(53546011)(6506007)(476003)(305945005)(26005)(446003)(8676002)(8936002)(14454004)(6116002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4966; H:BYAPR05MB4248.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aQcEv3wPtBCoNrtRopiSfpMCB5INmKVC49DQaiRGHHM2zZxUbJ1aVG8w6IL1Rjy2wq+fm4SIwacLXonar5NoZjU7PbHhLCr+8t2gldpMdCpQ6t5+KxQFzm6gleIGCHpCgZvttfLbL+ElEwfSPJ+OV6YIFfeDxnmGdFsDpGJlht1iInjrhTlpSQ4l8JhCDY4W0IcOslSu+gDDBmQJRWrH3XZn+02UxMp0EeGoi4rnu7WJA2XQ6oWwHBXnIvCc2Sj7MZNe8WlttmE0mb+LaRZzd9iAzDFB0BAyIiIo6O17+c2ic5JpLS8wPAUeNssCbqGBvdH/oF5z+JTbtL/S7f1cdURwxs1Ivo1mIKev4WitAADci5LeyAUlVDtlvvqikkTasv2BWh+wwHD5TVNEzfzyk6Jk8hHd6ykavgigFiRHJ15EThh+Jxlo6f+eWr6IohJlTB8ipEhLlW4eYOHYiHn7KjMg9T/SX9+fpC+n/v+QsLA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ac9d1081-f422-4225-5466-08d762ea8df9
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 18:53:03.8911 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: j5lR1YGmHml+JGrJ+A+V/1ivElVs7NVfvAeQ4f/LU0eirjajBJO9UB1wl3+LRoLjrj2663GTvYLE8B+kJI9s2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4966
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-06_06:2019-11-06,2019-11-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 suspectscore=0 adultscore=0 phishscore=0 clxscore=1031 priorityscore=1501 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911060184
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ih7SP4FBIVZqJFm0_Tm3dPn4DnQ>
Subject: Re: [Rats] Out-of-band key material set up in architecture document
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: Wed, 06 Nov 2019 18:53:14 -0000

Hi Dave,
  I agree that some kind of key is essential to attestation.  
  I don't want to make a statement of RATS architecture, but the RIV draft calls for the use of a manufacturer-installed DevID credential.  In the TPM world, the key corresponding to the DevID would be generated inside the TPM, so no one would have access to it (assuming you trust your TPM vendor!).
  /guy



Juniper Business Use Only

-----Original Message-----
From: RATS <rats-bounces@ietf.org> On Behalf Of Henk Birkholz
Sent: Wednesday, November 6, 2019 12:14 PM
To: Laurence Lundblade <lgl@island-resort.com>om>; Dave Thaler <dthaler@microsoft.com>
Cc: rats@ietf.org; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Rats] Out-of-band key material set up in architecture document

Hi Dave,
hi list,

the scope of the architecture was discussed a lot. It is okay to provide a bigger picture here, as the "phasing approach" will allow to talk about the attestation provisioning flows later on. Ben accompanied that decision process and I think he might be able to restate that :)

I think we are all in wild agreement here wrt to:

> "the manufacturer must put it there”, is however I think too narrow

We do not have to be prescriptive about any things here anyways, but to be descriptive or illustrative is very helpful.

In this quite prominent scenario:

> In some arguably more secure designs, the device itself creates the 
> key pair and the manufacturer per se never knows the private key, only 
> the public key,

the manufacturer provisioned something that made this happen (and therefore took measures to render the public key meaningful).

Viele Grüße,

Henk

On 06.11.19 17:58, Laurence Lundblade wrote:
> 
> 
>> On Nov 5, 2019, at 3:40 PM, Dave Thaler <dthaler@microsoft.com 
>> <mailto:dthaler@microsoft.com>> wrote:
>>
>> Inline below…
>> *From:*RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>>*On
>> Behalf Of*Laurence Lundblade
>> *Sent:*Tuesday, November 5, 2019 12:17 PM *To:*rats@ietf.org 
>> <mailto:rats@ietf.org> *Subject:*[Rats] Out-of-band key material set 
>> up in architecture document An issue I have with both the current 
>> architecture documents is that they do not discuss the need for some 
>> out of band key material set up to make verification work.
>>
>>     The manufacturer of the device must put some private key into each
>>     device so that the device can sign attestation evidence. Most
>>     likely the manufacturer also creates the verifying key material,
>>     but they may or may not be the verifier.  If they are not the
>>     verifier, somehow the verifier of attestation evidence must have
>>     corresponding key material to verify the signature.
>>
>> This paragraph could be a start of the text. I think this is a 
>> critical part of the architecture because attestation doesn’t work 
>> without it.
>> I agree that a private key is needed in each device for attestation 
>> to work (at least using any techniques I’m aware of). Saying “the 
>> manufacturer must put it there”, is however I think too narrow, as it 
>> implies the manufacturer actually knows the key. In some arguably 
>> more secure designs, the device itself creates the key pair and the 
>> manufacturer per se never knows the private key, only the public key, 
>> so it would be confusing to say the manufacturer “put” it there, or 
>> that the “manufacturer creates” the key material.
> 
> We could say “establish the signing key”? Certainly don’t want to 
> exclude those more secure designs.
> 
>> ...
>> Furthermore, the RATS charter does not constrain attestation to only
>> **hardware** based roots of trust.
>> There are some cases where it may be in a hypervisor or bios or 
>> firmware or whatever, and only attest things above that, with 
>> obviously a weaker level of security than hardware-rooted 
>> attestation.   But any protocol mechanisms should still work (mainly 
>> because it’s almost impossible to rule them out except via a security 
>> policy that says which keys to trust), even if it’s not the primary 
>> focus we care most about.  The point here being that in such a case 
>> it may not be the “manufacturer”, but may be another entity.  That’s 
>> actually true in some cases even for hardware-based roots of trust.
> 
> Yes, the “manufacturer” could be a SW vendor or even the author of a 
> dumb Android app. We need a much broader term or description.
> 
> LL
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats
> __;!8WoA6RjC81c!S7VupAZvpNNzm2WeDBek0LrW0vg400DQtY0GLzx8gtgBlX_gBhek44
> nCPoX8OEZiLLs$
> 

_______________________________________________
RATS mailing list
RATS@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!S7VupAZvpNNzm2WeDBek0LrW0vg400DQtY0GLzx8gtgBlX_gBhek44nCPoX8OEZiLLs$