Re: [Rats] Call for Adoption: EAT draft
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 23 May 2019 15:37 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.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 2C8AA120110 for <rats@ietfa.amsl.com>; Thu, 23 May 2019 08:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TNXFRRbhkZYn for <rats@ietfa.amsl.com>; Thu, 23 May 2019 08:37:13 -0700 (PDT)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F10120143 for <rats@ietf.org>; Thu, 23 May 2019 08:37:13 -0700 (PDT)
Received: by mail-oi1-x236.google.com with SMTP id f4so4697930oib.4 for <rats@ietf.org>; Thu, 23 May 2019 08:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uGz/Qlaz2YMm+dKERUV73Uf5odHnJVc2MLG+Gde0WpQ=; b=L8eiuZnkXqyTarGKw+isgRYoQV4hoeOak4oWMMqJlYPySED8e00gyki2ppaXIi47ZU o9MfmtgByryXdpPXIXK2v/zLZbutlYHcBt/3LlFJmBguxtc6uIQqf82d7PfCCTN2b/i6 NUNuKZzSeBaBCpUW3t3kgNPxwrBHMFCJl3NZzFWeRIYahmZaA4i0w1e7TtrjubMnykIj ziuY2LO7+MxXmZXnIi85ZCXRYStjLrrD6BB336ou0h3Bb8oRzX66yM/lUWoJWHmibc0H UWN1G2Grbfmp0wOo5J5vNfc7UdKAIFdYIbZr+hPDcRKz2rLQoTT86mHTQEOioActSJfy Pn5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uGz/Qlaz2YMm+dKERUV73Uf5odHnJVc2MLG+Gde0WpQ=; b=I68toxePT/8KiK8ci1S5+8BB5Uj/auIZjO2IDevS8DZ7cF516Y1rtWyXoIG7JcEjQE xosmfxMzVjhGJ/8Plc1cg0LeH+u68OH5FozEw0oJKuIZuliEJDrFrmKQe/SlkXnxybLu LqWzeCfOsyYEk0MbuCYwmjHCmk2AD31g6icU/KZJK4FhZ7nSzjvNs6myBMhhMkZmWWZh 555fO4XCALCgR6pkRFTz8YIOWhyvoJBrQU2qW8HUMAFuB6OXdQbbnDvzd7nEUSAOKi4G lh2mWDYzB3OJ+R3RddL/8gsEp3TQp/2BW+siYRJlQ7dzunjcwhtqnhjDmrfhch576hyk CnYg==
X-Gm-Message-State: APjAAAXW0EBmqbcVRzCJhKuiSfAhqR/utqj+DagBlgQuiga65S2EggHy fKWrcISE+KjRLJfGQcVOdVf31EZY4++/KXx5ftnvM97Q
X-Google-Smtp-Source: APXvYqzZrojcg/TvstgkzUTF8LaxLmKHV9y85oNVWBi1NoV5Gsji1L5FaGCu5lGwqqhZX2ar0HH8i/ypdhY+XBFnvJw=
X-Received: by 2002:aca:3d54:: with SMTP id k81mr2911641oia.111.1558625832329; Thu, 23 May 2019 08:37:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbuEH6Mdwp+neWbcecA-pMYZoXKiNda2A0EnMh-8WX=W9_edA@mail.gmail.com> <124ACA8D-6209-440C-99E4-B82A24FC18D1@tzi.org> <DBBPR08MB4539FA533892FA012E61216EFA010@DBBPR08MB4539.eurprd08.prod.outlook.com> <CAHbuEH42_fDxH75ndG50zGF1=Uj6u2iDZ2mMAWt2rgcOUVX9aw@mail.gmail.com> <af35d9c5-2033-b046-3ddd-9c8598995105@sit.fraunhofer.de>
In-Reply-To: <af35d9c5-2033-b046-3ddd-9c8598995105@sit.fraunhofer.de>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 23 May 2019 11:36:35 -0400
Message-ID: <CAHbuEH6+N5YeopwuneJ0jedBgTAJ6E+oBnQx7PLS4L=cS6jhgQ@mail.gmail.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: rats@ietf.org
Content-Type: multipart/alternative; boundary="00000000000012e6b505898fdb80"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/b2GbViXyalkH0CItibR-hKVchUg>
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: Thu, 23 May 2019 15:37:23 -0000
Hi Henk, On Thu, May 23, 2019 at 11:22 AM Henk Birkholz < henk.birkholz@sit.fraunhofer.de> wrote: > Hello Kathleen, > > I just posted a list of recommendations wrt the EAT I-D. Not all of > these are editorial, I think. > Great. We can make technical and editorial edits in adopted drafts, that's not an issue, it's expected. Best, Kathleen > > Viele Grüße, > > Henk > > On 5/23/19 3:49 PM, Kathleen Moriarty wrote: > > Chair hat off - > > > > On Thu, May 23, 2019 at 7:54 AM Hannes Tschofenig > > <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> wrote: > > > > Hi Carsten, > > > > You have been around when CWT defined but let me provide a history > > for those who weren't. > > > > The CWT was defined in ACE to correspond to a JWT. CWT uses CBOR > > together with COSE while the JWT uses JSON with JOSE. > > The CWT spec aimed to provide an easy mapping of claims already > > defined for the JWT. The JWT, a standardized access token format, is > > widely used in OAuth deployments and because ACE-OAuth uses, as the > > name indicates, OAuth as a foundation it created a "more lightweight > > version" of the JWT in form of the CWT. Defining an alternative > > token format for use with OAuth was possible because in the OAuth > > architecture the format of the access token is opaque to the OAuth > > Client. > > > > The CWT and the JWT have been defined for the OAuth authorization > > framework but they have later been used in other context too. Is > > this useful? It seems that the idea of having signed/encrypted/MACed > > claims is something people want to use even if different claims are > > used in different environments. Do they use different names then for > > these tokens (similarly what we do here with EAT)? Of course. People > > working in standardization like to come up with new names. That's > > why there are things like the "protection API access token (PAT)" or > > the "persisted claims token (PCT)". > > > > Is a token, like the CWT or the JWT, now a protocol message, a > > "document" or what? If you don't send it around then it does not > > seem to be a message. Not sending a token anywhere wouldn't be too > > useful either. The question I have is: does it matter? From a > > practical usage point of view you will have to send it around and it > > will be part of some message. I personally don't call it message or > > protocol but that's just me. There are claims defined for CWTs and > > JWTs that provide some meta-data, such as allowing to restrict its > > validity (time-based and even to a one-time use), or information > > that indicate when it was created. > > > > > > I'd say it is a CWT. CWT was built so that you could add new claims and > > the plan for EAT is to register these. If editors agree, we are down to > > editorial changes on a well developed specification. I support adoption. > > > > Best regards, > > Kathleen > > > > > > The main use case for attestation is a bit different than OAuth or > > ACE-OAuth because in OAuth/ACE-OAuth the access token gets created > > by the Authorization Server and is consumed by the Resource Server. > > While this is a possible use case also for RATS (when combined with > > an OAuth-based system, as folks in the OAuth group had suggested), > > the main use case (at least from my point of view) is that a device > > creates the token and then passes it on to the party that wants to > > verify it. > > > > If the EAT document uses the same structure as a CWT but defines new > > claims should you therefore say that "it is" a CWT or should one > > rather say "it is like" a CWT. I think it a matter of taste. I do > > not care - pick something. > > > > So, can you use claims defined already in an EAT token? Sure, you > > can. Will all the claims defined in the past be useful for an > > attestation context? Probably not. Will there be organizations > > defining profiles what claims they expect to see in an attestation > > token in a given deployment? Absolutely. GP, for example, is already > > working on it. > > > > In a nutshell: EAT is a simple effort and that's a good thing. This > > is why we implemented it and it is waiting for you to use it. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> On > > Behalf Of Carsten Bormann > > Sent: Mittwoch, 22. Mai 2019 21:25 > > To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com > > <mailto:Kathleen.Moriarty.ietf@gmail.com>> > > Cc: rats@ietf.org <mailto:rats@ietf.org> > > Subject: Re: [Rats] Call for Adoption: EAT draft > > > > > The Entity Attestation Token (EAT) > > > https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/ > > > > > > This begins a 2 week period to determine interest in adopting > > this draft as a working group item. The poll will close on May 24th > > EOD PDT. > > > > Hi Kathleen, > > > > I am definitely interested in this work. This is important, and I’d > > like to be able to convince myself we are doing it right. > > > > I apologize for maybe being a bit slow on the uptake, but currently > > I don’t have enough data to make a decision that the present > > document is on the trajectory yet where I’d normally ask for WG > > adoption. Maybe this adoption call simply is a few weeks (draft > > revisions) too early. > > > > While we can fix a lot of details in the WG process, I’d like to > > understand some fundamentals before committing to the trajectory I > > don’t understand. > > > > For instance, I’d like to understand whether an EAT is a token or a > > protocol message in some as yet undescribed protocol. E.g., there > > is the 11, nonce. Is this the same thing that would be 7, cti in > > RFC 8392? Or is it really something that is about an attestation > > protocol? If this is a nonce, what does the “nonce” mean? A > > single-use token? A nonce that isn’t quite a nonce but only can be > > reused in a limited context? How does the nonce bind to that > context? > > > > More generally, I’d like to understand whether an EAT *Is* a CWT, or > > *Is like* a CWT. > > Can I put in an “exp” claim? If yes, why do we need a new CBOR tag > > for something that essentially is a CWT? Wouldn’t it be useful to > > explain when a CWT is an EAT and when it is just a plain CWT? > > Tagging outside the COSE sign/mac isn’t enough (an attacker can > > change the tag and make a confusion attack). Is this spec really > > the place to define a “loc” claim and its subclaims? Is subclaims a > > concept that is only for EATs or is it for CWTs in general? > > > > I could go on explaining my lack of understanding here, but I think > > it should be clear that there are a lot of questions on *what* we > > are doing here (as opposed to *how* we are doing it, which is what > > the WG process is good for nailing down). A couple of iterations on > > this document might allow us to make a much better case that this is > > indeed going to be one of the base documents for the WG. Or maybe > > it really is a couple or three documents waiting to hatch from the > > eggshell. We still have > 6 weeks before I-D deadline for Montreal > > to clean this up. > > > > Grüße, Carsten > > > > _______________________________________________ > > RATS mailing list > > RATS@ietf.org <mailto: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. > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > 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 > -- Best regards, Kathleen
- [Rats] Call for Adoption: EAT draft Kathleen Moriarty
- Re: [Rats] Call for Adoption: EAT draft Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Rats] Call for Adoption: EAT draft Jeremy O'Donoghue
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Smith, Ned
- Re: [Rats] Call for Adoption: EAT draft Carsten Bormann
- Re: [Rats] Call for Adoption: EAT draft Ira McDonald
- Re: [Rats] Call for Adoption: EAT draft Kathleen Moriarty
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Kathleen Moriarty
- Re: [Rats] Call for Adoption: EAT draft Henk Birkholz
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Henk Birkholz
- Re: [Rats] Call for Adoption: EAT draft Kathleen Moriarty
- Re: [Rats] Call for Adoption: EAT draft Simon Frost
- Re: [Rats] Call for Adoption: EAT draft Anders Rundgren
- Re: [Rats] Call for Adoption: EAT draft Jeremy O'Donoghue
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Anders Rundgren
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Laurence Lundblade
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Giridhar Mandyam
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Laurence Lundblade
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Simon Frost
- Re: [Rats] Call for Adoption: EAT draft Henk Birkholz
- Re: [Rats] Call for Adoption: EAT draft Smith, Ned
- Re: [Rats] Call for Adoption: EAT draft Hannes Tschofenig
- Re: [Rats] Call for Adoption: EAT draft Laurence Lundblade
- Re: [Rats] Call for Adoption: EAT draft Henk Birkholz
- Re: [Rats] Call for Adoption: EAT draft Eric Voit (evoit)
- Re: [Rats] Call for Adoption: EAT draft Simon Frost
- Re: [Rats] Call for Adoption: EAT draft Kathleen Moriarty