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