Re: [Rats] Call for adoption (after draft rename) for Yang module draft

"Smith, Ned" <ned.smith@intel.com> Mon, 11 November 2019 18:35 UTC

Return-Path: <ned.smith@intel.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 78883120B85 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 10:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ymZdsrZbHr4M for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 10:35:54 -0800 (PST)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 D8FB5120A68 for <rats@ietf.org>; Mon, 11 Nov 2019 10:35:52 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2019 10:35:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,293,1569308400"; d="scan'208";a="213826370"
Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2019 10:35:52 -0800
Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 11 Nov 2019 10:35:52 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX154.amr.corp.intel.com ([169.254.11.36]) with mapi id 14.03.0439.000; Mon, 11 Nov 2019 10:35:51 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Laurence Lundblade <lgl@island-resort.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad/EtmAgAAHhgCAAAO0AIAGacyAgAAGuoCAAJAygIAAL78AgACJSwD//32CgA==
Date: Mon, 11 Nov 2019 18:35:51 +0000
Message-ID: <DB352EF5-C211-46EE-BFF2-223372AB9AEC@intel.com>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <47faa9a4-9bb1-751f-2b5a-71e020659514@sit.fraunhofer.de>
In-Reply-To: <47faa9a4-9bb1-751f-2b5a-71e020659514@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-originating-ip: [10.251.18.104]
Content-Type: text/plain; charset="utf-8"
Content-ID: <84B0593241A2FA47830E0873FB6450E5@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/MDls0P-vbKtORbUyonHb7FO0KF8>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Mon, 11 Nov 2019 18:36:00 -0000

Given the architecture supports hybrids of passport and background check models, it seems there could be a rich combination of attesters, verifiers and relying parties where partial results could be supplied by Verifier A to RP B who in turn verifies as Verifier B and produces results B etc... If so, then possibly a TPM encapsulated "claim" gets passed on to multiple verifiers until one that can parse a TPM encapsulation is found. Maybe this is a contrived use case, but it seems reasonable based on what has been discussed so far. By not allowing a TPM encapsulation, it implies there is some other encapsulation besides a "Token" that carries the TPM produced Evidence. 

-Ned

On 11/11/19, 10:23 AM, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de>; wrote:

    Laurence provided options as a basis for discussion a while ago.
    
    He highlighted that CWT must be signed and illustrated pro & con wrt:
    
    * null cipher,
    * an "unsigned" flavor of CWT
    * an "arbitrary signature"
    
    It might be a valid assumotion that a single "tpm Claim" would have no 
    significant added value, but multiple Claims in a message bundle might 
    (although this might be a solution looking for a problem?).
    
    Viele Grüße,
    
    Henk
    
    On 11.11.19 19:11, Smith, Ned wrote:
    > Right. This implies the RATS “token” should support existing “binary” 
    > formats as an encapsulation (signed by a second TA where the TPM is a 
    > first TA) or as a conveyance (unsigned?) token. Possibly, the only added 
    > value of the latter is a tag that identifies it as a TPM binary format?
    > 
    > On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - 
    > FI/Espoo)" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> on 
    > behalf of ian.oliver@nokia-bell-labs.com 
    > <mailto:ian.oliver@nokia-bell-labs.com>> wrote:
    > 
    >> Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that > EAT will replace TPM attestations  in the long run (maybe decades) because they are far more expressive. 
    > I know > others believe that too.
    > 
    > I would disagree with the statement of "short run" ... TPM is 
    > practically the only existing standardised (hardware, software, 
    > firmware, measurement - x86 only etc) hardware root of trust in common 
    > use, ie: practically all x86 machines,  The attestation mechanisms 
    > provided are going to be around for a very long time.
    > 
    >  From telco experience, 30 years ago we said SS7 would only be around in 
    > the short term.
    > 
    >> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise > to add EAT to it.
    > 
    > Agree
    > 
    > Ian
    > 
    > -- 
    > 
    > Dr. Ian Oliver
    > 
    > Cybersecurity Research
    > 
    > Distinguished Member of Technical Staff
    > 
    > Nokia Bell Labs
    > 
    > +358 50 483 6237
    > 
    > ------------------------------------------------------------------------
    > 
    > *From:*Laurence Lundblade <lgl@island-resort.com>;
    > *Sent:* 11 November 2019 00:44
    > *To:* Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>;
    > *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>;; rats@ietf..org 
    > <rats@ietf.org>;
    > *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang 
    > module draft
    > 
    >     On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)
    >     <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> wrote:
    > 
    >     So, Laurence, are you still OK with the adoption of the current
    >     draft with a rename for now?
    >     Thanks, Nancy
    > 
    > I think the value add to the larger RATS effort of adding EAT support to 
    > this YANG protocol is really high. It a core thing to do that helps 
    > bring together the two attestation worlds and make the TPM and EAT work 
    > here less like ships in the night.
    > 
    > Remote TPM attestations are useful and necessary the short run, but are 
    > of very limited capability. I believe that EAT will replace TPM 
    > attestations in the long run (maybe decades) because they are far more 
    > expressive. I know others believe that too.
    > 
    > If we don’t include EAT in the YANG mode it is sort of like defining 
    > HTTP to only convey HTML to the exclusion of PDF. We’re defining an 
    > attestation protocol that can only move one kind of attestation even 
    > though we have consensus on what the other one looks like.
    > 
    > It seems relatively simple to add EAT support (or promise to add EAT 
    > support). Pretty sure I heard Henk agree to add it.
    > 
    > Thus, I am opposed to adoption with the current TPM-only draft. I’d be 
    > OK with the current draft and a promise to add EAT to it.
    > 
    > LL
    > 
    
    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats