Re: [Rats] Call for Adoption: EAT draft

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 31 May 2019 14:42 UTC

Return-Path: <evoit@cisco.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 2DB9F120052 for <rats@ietfa.amsl.com>; Fri, 31 May 2019 07:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BXsHFEsZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QFTcGuLr
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 oDsXthhdRejl for <rats@ietfa.amsl.com>; Fri, 31 May 2019 07:42:12 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FC31200A1 for <rats@ietf.org>; Fri, 31 May 2019 07:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12870; q=dns/txt; s=iport; t=1559313720; x=1560523320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g8t2lJToYe5X9c2ItLd5aRpph51bBwmIDdnMK1/0itI=; b=BXsHFEsZluUcoO3FxudJO9Nsnh3wXv7sIlQrjAvXn+jGiI6kkRDc2HXX /4teCeiOqSOgme2bCPQGsrFC/hat/p32XbxbGcYeabLQBQaqvMXG2PO1z NeVFyrBfCndHMrzEOCAM0RRDfBIrekCTPJcIuffeIuteO4N6F9/YOJKBY g=;
IronPort-PHdr: 9a23:YNtPhBVNhoz1b0RyODwxHKOFZtzV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSANWJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank3AsNDSHdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAAAXPPFc/5JdJa1lGgEBAQEBAgEBAQEHAgEBAQGBUgQBAQEBCwGBPSknA2lVIAQLKAqECoNHA45ygleXL4EuFIEQA1QJAQEBDAEBGAsKAgEBhEACF4JtIzUIDgEDAQEEAQECAQRtHAyFSgEBAQMBAQEQCwYRDAEBKQIBAgkBBAcEAgEIEQQBAQECAiYCAgIlCxUICAIEAQ0FCBIIgwGBagMODwECDJ9IAoE4iF9xgS+CeQEBBYUCGIIPAwaBDCgBijmBAR0XgUA/JmtGgU5+PoJhAQGBLgESARIPFYJzMoImiyoICoJamXZqCQKCDY54hFGCIS+GQoQCiVOMepYXAgQCBAUCDgEBBYFRAjRncXAVO4Jsgg+BJQECCoI+hRSFP3KBKYsFDReBCwGBIAEB
X-IronPort-AV: E=Sophos;i="5.60,535,1549929600"; d="scan'208";a="348120412"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 May 2019 14:41:57 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x4VEfvpB003218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 May 2019 14:41:57 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 May 2019 09:41:56 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 May 2019 10:41:55 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 May 2019 09:41:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g8t2lJToYe5X9c2ItLd5aRpph51bBwmIDdnMK1/0itI=; b=QFTcGuLr5MHNQCstl7c9L341GshTOQlcwIBnzlWFzEhxjF1JQSUh6hctFBIoiN4Pva11rJ7Dnaut8S4GeY3/xoOst4ZH1wcMG7V8972wo9s4TH02tdO+D+EOJta9ZlGwtQgyR4hbeWGvRG1AzlIxKNiVTig5kFxEer8j8l2+ses=
Received: from DM6PR11MB4089.namprd11.prod.outlook.com (20.176.126.30) by DM6PR11MB3308.namprd11.prod.outlook.com (20.176.121.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.17; Fri, 31 May 2019 14:41:53 +0000
Received: from DM6PR11MB4089.namprd11.prod.outlook.com ([fe80::d014:d7a3:270:e5a9]) by DM6PR11MB4089.namprd11.prod.outlook.com ([fe80::d014:d7a3:270:e5a9%3]) with mapi id 15.20.1922.021; Fri, 31 May 2019 14:41:53 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, Giridhar Mandyam <mandyam@qti.qualcomm.com>
Thread-Topic: [Rats] Call for Adoption: EAT draft
Thread-Index: AQHVB0JFcFAs6WTeOkGyPcUokje8h6Z3f+WAgAkvdwCAAAQPAIAAQeOAgAAaP4CAAAwUgIAADicAgAAZOwCAAAfHAIACt1gAgAAFvJCAAA1BIIAAVb6AgACS14CAAGj3AIAAAPcA
Date: Fri, 31 May 2019 14:41:53 +0000
Message-ID: <DM6PR11MB4089CA58E8ACC7A347A2B99AA1190@DM6PR11MB4089.namprd11.prod.outlook.com>
References: <CAHbuEH6Mdwp+neWbcecA-pMYZoXKiNda2A0EnMh-8WX=W9_edA@mail.gmail.com> <DM6PR11MB408991CBF9B50672E12A8F61A1000@DM6PR11MB4089.namprd11.prod.outlook.com> <DM6PR11MB4089818BBEF529569DC1250DA11E0@DM6PR11MB4089.namprd11.prod.outlook.com> <bdcaa9f2ca2344aa98287acd0b80d8f3@NASANEXM01C.na.qualcomm.com> <DM6PR11MB408939CC9EA79D479B76586DA11E0@DM6PR11MB4089.namprd11.prod.outlook.com> <E09EB1B2-ED56-4F1B-8D80-BF0D227199A3@island-resort.com> <82b0a75e5b5645d1a43d240373bca6dc@NASANEXM01C.na.qualcomm.com> <DM6PR11MB4089DAD248EEAAF9F92F2C0AA11E0@DM6PR11MB4089.namprd11.prod.outlook.com> <50ddca72a9074e229976ca88f78e340a@NASANEXM01C.na.qualcomm.com> <DM6PR11MB4089BF4C3F319894DAE8722AA11E0@DM6PR11MB4089.namprd11.prod.outlook.com> <175ea22d1a1948d48f8180424cc89ec0@NASANEXM01C.na.qualcomm.com> <VI1PR08MB5360CE8EFA93515A140D30F2FA180@VI1PR08MB5360.eurprd08.prod.outlook.com> <DM6PR11MB408967D6E5EF0A355CF0D60BA1180@DM6PR11MB4089.namprd11.prod.outlook.com> <D53ECF26-E2F5-4BD5-A81F-BBE1AEEB4541@island-resort.com> <VI1PR08MB5360919E4669734878D75F6EFA190@VI1PR08MB5360.eurprd08.prod.outlook.com> <VI1PR08MB53608BBD4BC156012237D3C6FA190@VI1PR08MB5360.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB53608BBD4BC156012237D3C6FA190@VI1PR08MB5360.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.74]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b96eeec7-8106-4a15-f8c1-08d6e5d61f63
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB3308;
x-ms-traffictypediagnostic: DM6PR11MB3308:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM6PR11MB3308E5D886B343A4996D8AE1A1190@DM6PR11MB3308.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 00540983E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(39860400002)(366004)(396003)(13464003)(199004)(189003)(6116002)(66556008)(66476007)(14454004)(6506007)(53936002)(66066001)(64756008)(33656002)(966005)(76116006)(86362001)(7696005)(73956011)(305945005)(446003)(110136005)(81166006)(81156014)(99286004)(66946007)(7736002)(8676002)(26005)(229853002)(256004)(14444005)(66446008)(5024004)(53546011)(186003)(6436002)(54906003)(3846002)(2906002)(476003)(6306002)(478600001)(102836004)(561944003)(316002)(68736007)(486006)(71190400001)(25786009)(5660300002)(8936002)(4326008)(6246003)(74316002)(76176011)(52536014)(11346002)(55016002)(9686003)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3308; H:DM6PR11MB4089.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: f44KhNegr04wk2wDUHtnDdNvbfA86p5eZC4yt8KUj0EU9b7bnh1A8vtJmcN19izgN9Wu5rdURT+U7sb+qXEgvzx3adHJGtLz1AgHGF0OSdhbOEFZYzpptXT/jzjdupsc5EGGKEn1kMmgHfqmqITJpbugTIc7f/oi8aJGd20lrPP7sktFTjqAY0C495fIDXqOHq44uIJNabdRxxaMiH2jXeS4sBvA15vi3FhLTKgtcCq/+MzZ/IuzDdPmCBFZ2vim2fqT0znC8L02iEAix7wUUjznkevhh4IUgZ43JJMvnfbYs6lQGAGC/QTH09q1oCQZRWkkpainw6gt0U720azez0Kdo3ha4jbaxPD+NbjOm16y08UmPLR8njJmo0FBVoeNV1HwNFD0HcuDmkmox+a54p1sm2hVgz/HFXccpgFiuis=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b96eeec7-8106-4a15-f8c1-08d6e5d61f63
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2019 14:41:53.1531 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: evoit@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3308
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/P0pbR2nXB7z1V5Q2RmpEJReuTHE>
Subject: Re: [Rats] Call for Adoption: EAT 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: Fri, 31 May 2019 14:42:15 -0000

Hi Hannes,
Hi Laurence,

> From: Hannes Tschofenig, May 31, 2019 10:10 AM
> 
> Hi Eric, Hi Laurence,
> 
> I thought about this a bit more.
> 
> If I understand it correctly then your main concern is that we duplicate
> information in the CWT claims registry that is already available in other
> registries. Is my understanding correct?

Yes, this is the main concern.   I am not against duplication for good reasons.  I am against unconscious duplication which places the reconciliation role fully downstream.

> I also hear a second concern, which is more about whether the existing CWT /
> JWT registry contains claims that are not suitable for use in an EAT token.

I only brought up the location example when pressed.  I am less worried about location than future 'TBD object' claims.  Earlier assertions is this thread hinted that any object might be suitable to become a claim in the registry.
 
> Underlying both concerns is the question about what makes for a good claim for
> use within an EAT token. Do we know the answer?

I don't know the answer.
 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Hannes Tschofenig
> Sent: Freitag, 31. Mai 2019 09:55
> To: 'Laurence Lundblade' <lgl@island-resort.com>; Eric Voit (evoit)
> <evoit@cisco.com>
> Cc: rats@ietf.org; Giridhar Mandyam <mandyam@qti.qualcomm.com>
> Subject: RE: [Rats] Call for Adoption: EAT draft
> 
> Hi Laurence, Hi Eric,
> 
> > So if an EAT is a CWT, then the proposal is to change the IANA registry rules
> for CWT in the EAT draft. Is that allowed? This is really a change to CWT and
> even JWT. Seems like it is saying that if a YANG-defined claim exists for a
> possible CWT or JWT claim, the YANG-based claim MUST be used.
> 
> IMHO everything can be changed.

I also believe things can be changed.  This is one of the reasons at the beginning of my comments I asked what the domain of possible claims might be.   Our IETF management processes must reflect the volume and provenance of claim types. 

As for me saying that claims MUST be YANG based, I certainly didn't mean to imply that.    What I wanted to say is that if downstream claim users have existing objects defined analogous to these claims, we should adopt these where possible.   These object might or might not be based on YANG.   But for Routers/Switches, YANG is where most of the recent object definition work has been happening.  

If there are no such analogous objects, we should feel free to define whatever we want.  However I suspect such 'green-space' objects will be rare.

> > I think Eric’s thought about harmonizing is a good one. Learn from past
> efforts. Improve interop.
> 
> Learning from past efforts sounds always good. Let me pick on the example
> from below about draft-ietf-netmod-geo-location-01. It appears to me that the
> netmod group has either not looked at the work from the IETF GEOPRIV working
> group or ignored it. (I have not been involved in the netmod group and so I
> cannot say.) GEOPRIV published a number of RFCs that provide details about
> how to encode different geodetic location shapes (based on a mapping from
> GML), civic location, relative location, talks about uncertainty and confidence,
> how to encode moving objects, etc. While there is no need to use the info 1:1
> there is a lot that can be learned from the work in that group. Of course, the
> content for the location encoding in draft-mandyam-eat-01 isn't much better.
> 
> For me the biggest question is whether location is actually a good source of
> information conveyed in an EAT token.

I don't have a strong opinion on that.  But I can at least imagine a hardened GPS chip which signs its received location.
 
> Eric, I understand that you do not want to duplicate information. I don’t want to
> do that either. I have been wondering about this aspect myself (particularly
> when I read the location claim). For example, in the LwM2M context we have a
> (pretty naive) location object as part of the data model as well. The data model
> we use with LwM2M is different to how data is modelled in the EAT token. Is this
> unavoidable? In some sense the situation is similar to the Yang-defined data
> model. The source of information comes from a different part of the system and
> is conveyed differently. Maybe you could call it a different layering where a
> device with Yang objects has to treat the EAT token as opaque (particularly since
> it is digitally signed and potentially encrypted). I am currently leaning towards
> seeing it that way from a LwM2M perspective.

I really don't have a strong opinion on this.  But I like that we are having the discussion.

Eric

> Ciao
> Hannes
> 
> ~ snip ~
> 
> However, IANA registry rules revising aside, making it a MUST seems too much. I
> think the YANG-defined claims should be very much seriously considered, just
> like any other previous data structure definition, but that there be no blanket
> requirement.
> 
> To go a little further and to be clear. When a YANG-defined claim is used the
> CBOR encoding of it will be used with CWT and the JSON encoding of it will be
> used with JWT. This hinges on draft-ietf-core-yang-cbor-10 producing satisfying,
> compact and sensible CBOR encodings (binary data is really CBOR binary, claim
> keys are small integers…).
> 
> LL
> 
> 
> > On May 30, 2019, at 12:19 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
> >
> > Hi Hannes,
> >
> > I do like EAT.  I am hoping that it gets adopted.
> >
> > At the same time, I am trying to avoid unnecessary mapping of claims from a
> chipmakers domain into system integrator /network operator domains.  I
> believe much pain can be avoided with a little planning up front.  That is what I
> am trying to facilitate with this discussion.
> >
> > Specific details/examples in-line...
> >
> >> From: Hannes Tschofenig, May 30, 2019 1:18 PM
> >>
> >> Hi Giri, Hi Eric,
> >>
> >> (a) some principles/guidance to CWT claims registry people on avoiding the
> mass registration of lightly-used or unused claims
> >>
> >> Why is this a requirement? When a claim is registered then it is most likely
> done with the anticipation that it will be used. I have not seen other IETF
> registries that have raised the bar to a similar level, at least the JWT claims
> registry does not work that way. Furthermore, what is the harm in registering
> claims that later turn out to be less frequently used?
> >
> > Let me provide a *best* case example.  In the NETMOD WG, there is a draft-
> ietf-netmod-geo-location.  Both that draft and this have definitions of latitude,
> longitude, altitude, accuracy, etc.   The *good* news is that both drafts are
> based on WGS84.  So at least our experts have lucked in to using a consistent
> resource.  But are these the same objects?  How does a reader know?   In one of
> the documents the latitude/longitude attributes are "FloatOrNumber", in the
> other they are "decimal64 {fraction-digits 16}".
> >
> > It of course gets harder for other objects.   The velocity objects in draft-
> mandyam-rats-eat are "heading" and "speed".  And draft-ietf-netmod-geo-
> location has this information "v-north", " v-east", and " v-up".  Here we have
> different formats, the first of which cannot be easily upgraded to serve three
> dimensions.
> >
> > And then we get into other harder objects where we will have timestamping,
> explicit domains of allowed entries, etc.  And is there is no boundaries on what
> might be claimed as an EAT, in theory we could create a parallel domain of
> objects without description on how to map between the two, placing the heavy
> lifting onto the implementer.
> >
> > Now I am not trying to solve world hunger in this thread.  I am just trying to
> have the draft consider minimizing inter-ecosystem friction where we can see it
> coming.  I believe with a little foresight we can ensure a consistent population
> and data typing for a subset of claims.   Without foresight, I see that people will
> create new CWT to avoid some later mapping.  And more/redundant CWT tags
> will harm interoperability.
> >
> >> (b) a requirement to map claims to existing YANG objects, if these YANG
> objects exist
> >>
> >> I also don’t understand this requirement. Is there some design rational why
> this would be needed/useful?
> >
> > Per above, EAT claim instances need to be integrated with other
> work/ecosystems in the IETF after the information comes off of a hardware
> chip.  A claim registry shouldn't create redundant info/formats to other
> work/ecosystems when it can be avoided, at least without broad discussion and
> consensus.   (I.e., lets avoid unconscious object definition and object domain
> overlaps wherever possible.)
> >
> > Eric
> >
> >> Cia
> >> Hannes
> > _______________________________________________
> > RATS mailing list
> > RATS@ietf.org
> > https://www.ietf.org/mailman/listinfo/rats
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.