Re: [Rats] More use cases for draft-richardson-rats-usecases-00

"Smith, Ned" <ned.smith@intel.com> Tue, 02 April 2019 17:27 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 5E48E1201D0 for <rats@ietfa.amsl.com>; Tue, 2 Apr 2019 10:27:25 -0700 (PDT)
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_PASS=-0.001, URIBL_BLOCKED=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 S-rB3oZZ3WZK for <rats@ietfa.amsl.com>; Tue, 2 Apr 2019 10:27:22 -0700 (PDT)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 9185912019F for <rats@ietf.org>; Tue, 2 Apr 2019 10:27:22 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2019 10:27:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,301,1549958400"; d="scan'208";a="139541419"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga007.fm.intel.com with ESMTP; 02 Apr 2019 10:27:21 -0700
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Apr 2019 10:27:21 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.11]) by ORSMSX153.amr.corp.intel.com ([169.254.12.88]) with mapi id 14.03.0415.000; Tue, 2 Apr 2019 10:27:20 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Carl Wallace <carl@redhoundsoftware.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] More use cases for draft-richardson-rats-usecases-00
Thread-Index: AQHU30/xj2BiBGEziUKa7njbv8kyH6YXXCyAgAD8bgCACDVrAIAArVGAgABAUYCAAAI3gIADCaQAgABTXoCAAPrVgIADXk8A
Date: Tue, 02 Apr 2019 17:27:19 +0000
Message-ID: <7B05ABC3-FE60-4879-9DEE-B896DD15507D@intel.com>
References: <MW2PR00MB03963ABEB87211AD28A16240A6490@MW2PR00MB0396.namprd00.prod.outlook.com> <12503.1552447661@localhost> <58E37DB5-098C-4387-9A52-4AECD0F69F25@island-resort.com> <6495.1553219901@dooku.sandelman.ca> <BA6E28A7-0F6A-46A8-AB1B-A64B9229F149@intel.com> <507.1553725386@dooku.sandelman.ca> <24C0968B-32B0-4EF1-99C8-61D3F0955BA1@intel.com> <793F9A34-050F-4914-AF4B-08C072730A06@island-resort.com> <D8C23800.D851F%carl@redhoundsoftware.com> <19652.1553943890@dooku.sandelman.ca> <D8C50A67.D8999%carl@redhoundsoftware.com> <79ccb2d7-09a3-913d-f47d-1e702a23b341@gmail.com>
In-Reply-To: <79ccb2d7-09a3-913d-f47d-1e702a23b341@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
x-originating-ip: [10.24.14.163]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5F0ED7910F38B349A55543A0583B96BD@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/SY9LAY9lKNcgrN_BrX4l3rZW-qI>
Subject: Re: [Rats] More use cases for draft-richardson-rats-usecases-00
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: Tue, 02 Apr 2019 17:27:31 -0000

Anders refers to session-based attestation in the TEEP archive which points to several sources including a TCG source. This may be referring to a public specification known as DICE - Device Identifier Composition Engine.  https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf 

TCG terminology for TEEP's "Static" attestation is "Explicit Attestation" and TEEP's term "Session Based" attestation is "Implicit Attestation" by TCG.

I.e.
(i) TCG.Implicit-Attestation ~= IETF.TEEP.Session-Based-Attestation
(ii) TCG.Explicit-Attestation ~= IETF.TEEP.Static-Attestation

The EAT draft defines an attestation approach that seems close to (i) if you ignore the nonce that is returned as a static claim / assertion and if you rule out of scope the definition of how the signing key is created / persisted. 

The tokbind draft seems closely resemble (ii).
The TUDA draft seems to resemble (i). (Henk can correct me).
The yang draft seems to resemble (ii). (Henk can correct me).

-Ned

On 3/31/19, 12:01 AM, "RATS on behalf of Anders Rundgren" <rats-bounces@ietf.org on behalf of anders.rundgren.net@gmail.com> wrote:

    On 2019-03-30 17:03, Carl Wallace wrote:
    > Makes sense to me to capture current artifacts. Maybe in an appendix to
    > the use cases draft.
    
    For completeness you should consider mentioning that there are two quite different platform attestation concepts:
    - Static: FIDO, Android, and current TEEP architecture
    - Session based: Used by some smart card schemes and SKS/KeyGen2 (https://github.com/ietf-teep/architecture/issues/52)
    
    > 
    > On 3/30/19, 7:04 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
    > 
    >>
    >> Carl Wallace <carl@redhoundsoftware.com> wrote:
    >>     > Example attestations from Android devices, Yubikey devices and
    >> Surface
    >>     > Pro virtual smart cards can be found here:
    >>     > https://github.com/Purebred/SampleAttestations. These are
    >> accompanied
    >>     > by SCEP requests that include the attestations and the resulting
    >>     > certificates. The attestations were generated and used as part of
    >>     > issuing device and end user certificates where the public key was
    >> the
    >>     > focus of the attestation. The Android and Yubikey attestations take
    >> the
    >>     > form of X.509 certificates (packaged as certs-only SignedData). The
    >>     > Surface Pro attestations take the form of CMC requests.
    >>
    >> I think that seeing the examples is very useful to extract common pieces.
    >> Do you think it's useful to include some in the use case document?
    >>
    >> -- 
    >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
    >> -= IPv6 IoT consulting =-
    >>
    >>
    >>
    > 
    > 
    > _______________________________________________
    > RATS mailing list
    > RATS@ietf.org
    > https://www.ietf.org/mailman/listinfo/rats
    > 
    
    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats