IETF Logo Mail Archive

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

"Smith, Ned" <ned.smith@intel.com> Thu, 05 December 2019 00:02 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 6E1C612004D for <rats@ietfa.amsl.com>; Wed, 4 Dec 2019 16:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 s6pyu2hTOqnv for <rats@ietfa.amsl.com>; Wed, 4 Dec 2019 16:01:58 -0800 (PST)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 99CC812002F for <rats@ietf.org>; Wed, 4 Dec 2019 16:01:58 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2019 16:01:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,279,1571727600"; d="scan'208";a="208971339"
Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga008.fm.intel.com with ESMTP; 04 Dec 2019 16:01:57 -0800
Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 4 Dec 2019 16:01:57 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX152.amr.corp.intel.com ([169.254.8.219]) with mapi id 14.03.0439.000; Wed, 4 Dec 2019 16:01:57 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Michael Richardson <mcr@sandelman.ca>
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/EtmAgAAHhgCAAAO0AIAGacyAgAAGuoCAAJAygIAAL78AgAEETQCAAqU5AIACdRAAgAyAhACAAE8NAIASB+CA//+RgAA=
Date: Thu, 05 Dec 2019 00:01:55 +0000
Message-ID: <E895051D-6F8F-4EF7-B08E-DFFF28A3AB91@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> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <6E7D64B4-2049-4D0A-ADC5-CA3F0647779B@island-resort.com> <MWHPR21MB07840B6CF7BEE0A11ABE54BFA3700@MWHPR21MB0784.namprd21.prod.outlook.com> <10511.1574490818@dooku.sandelman.ca> <8363AFEC-C92C-466D-8F2C-CE7A3E94370B@intel.com> <22086.1575499045@localhost>
In-Reply-To: <22086.1575499045@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.105]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FAD8BB7BC075D4CB3556EBC729DAB9E@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/MS2GvKi6gPxPn3JRalq3DAD8mkA>
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: Thu, 05 Dec 2019 00:02:00 -0000


On 12/4/19, 2:37 PM, "Michael Richardson" <mcr@sandelman.ca> wrote:

    
    Smith, Ned <ned.smith@intel.com> wrote:
        > The step-0 protocol may have payload size or timing limitations that
        > prevents fully attesting. This is the case for 802.1X ethernet ports.
    
    EAP-TLS would carry the certificate, and it has a way to segment the
    payloads, I think.  If not, DTLS does.
    
    The attestation would go into the TLS as data, inside the voucher-request, so
    I don't imagine that there would be further size limitations.
    

That is one approach, other approaches include Evidence in certificates. Sometimes protocols have upper bound on the size of the certificate path payload. Doing attestation as part of a session establishment (e.g. TLS handshake) is the trust semantics of attestation apply to the session keys. If attestation is part of a data block, then it is possible for the trust semantics of attestation to be separated from the session endpoints. 
    
        > _______________________________________________
        > RATS mailing list
        > RATS@ietf.org
        > https://www.ietf.org/mailman/listinfo/rats

v2.23.0 | Report a Bug | By Email