Re: [Rats] Call for Adoption: EAT draft

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 23 May 2019 17:36 UTC

Return-Path: <anders.rundgren.net@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 1953C120043 for <rats@ietfa.amsl.com>; Thu, 23 May 2019 10:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 R31kqz_LmTG9 for <rats@ietfa.amsl.com>; Thu, 23 May 2019 10:36:31 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 5E8431200C4 for <rats@ietf.org>; Thu, 23 May 2019 10:36:23 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id w8so7197836wrl.6 for <rats@ietf.org>; Thu, 23 May 2019 10:36:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qfTY6pjUyzBr7j4KImjLdFqp3umovhLEqHxwJ3O95Es=; b=mFDgcLHrlGNVYzt3epLzgwg83/WZpDOjYKcY88Mw/7YhcSog4ZrrCyUiHkwh7epQA5 iOYOm4PZrBbrmYKZw05sOj3kSes0157+Z6eViTbByIa311pdvz7zFlvHJoZIJIB6Vg0z nU3wLnC5Lutc1t8nAuGt6cKHdtI33bbWraqvmjO/7e2QXqByIjUfOHQg8xse808yxSDR 4jpZ7EW2EYafmlkT87E75+HNOPoNwG/pOG4aExhYa+uMEoZxT5Y7/ALbYha+gMEEza4b YX11hgaOyBHuowT0LtHXHQ6rISJXYoHIz+zWWSJOSdBzD7tKTsUc0Lc1TLAnjoPRPqrB jSZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qfTY6pjUyzBr7j4KImjLdFqp3umovhLEqHxwJ3O95Es=; b=WQsM6V/fCRMWgivDF+cfL7A1waf2A0g+yCPC/3h6fHS02abpiNrRH/oVok3c81Q5kB /y/IGzOiEXWRjLxu0JT1DrWYOXO9rw1kwxc6qldkPvaPc1oj0NY1QTEcOk/lE6HXxXmP SIW3FJfFmhwuiJqJSQieaSy4ibsiWEUlkJ01LxvWQUXfkXioWdxEAgPb1xY7eoFYcEZq TLNvt51G/Ha1q+26CU1Cp8qMOB1EOovVDNEiMiFma5GYKVZk3zpcwQWG/9qob1VdXcvP zJ8g708u+dOgEgLe9bxfBbXbDUr38qCXWrCz9W87efXOMTIkQbSjbnZwdotg/SQvxCnp 1Phg==
X-Gm-Message-State: APjAAAUwe2KBApvYtdmWeXiYDFSteQq+pf+9T7HED5zbjXe+ENjh2G2J Oa/sJ/71/NakslSJnEbMjQ4UHuDaPjE=
X-Google-Smtp-Source: APXvYqzyQnJzhEq089E6H58UrnFTzire4cm8Oha3O5IHPYVCuQYcqaNGM8hbwUqHYOgpUp8utNlDnA==
X-Received: by 2002:a5d:63c7:: with SMTP id c7mr1675050wrw.68.1558632981214; Thu, 23 May 2019 10:36:21 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id t12sm19987908wro.2.2019.05.23.10.36.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 10:36:20 -0700 (PDT)
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Carsten Bormann <cabo@tzi.org>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, "rats@ietf.org" <rats@ietf.org>
References: <CAHbuEH6Mdwp+neWbcecA-pMYZoXKiNda2A0EnMh-8WX=W9_edA@mail.gmail.com> <124ACA8D-6209-440C-99E4-B82A24FC18D1@tzi.org> <DBBPR08MB4539FA533892FA012E61216EFA010@DBBPR08MB4539.eurprd08.prod.outlook.com> <03c7fe24-d0ac-c96c-533c-13604433be08@gmail.com> <BBB0003A-1186-43DB-B95E-972A6045C7C5@qti.qualcomm.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <f1bd403c-b08d-fd74-e20c-e2cf90bfc1e5@gmail.com>
Date: Thu, 23 May 2019 19:36:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <BBB0003A-1186-43DB-B95E-972A6045C7C5@qti.qualcomm.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/8jwLPZ5rx4y7Ab--tRvEhWwrBmk>
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 17:36:34 -0000

On 2019-05-23 18:57, Jeremy O'Donoghue wrote:
> You could probably rewrite the messaging to use CWT, but...
> 
>  1. There are a lot of protocol aspects in OTrP that don't really map well into EAT. You would still need a protocol definition.
>  2. An awful lot of what is in OTrP would be difficult to classify as "claims" (some of the auditing information meets the definition, but something like "Install TA" is not really a claim.
>  3. There are deployments of OTrP out there already, and other specifications that build on it. I don't believe such radical change would be a good idea (or at least should no longer be called OTrP)

I have suggested an even more radical change
https://github.com/ietf-teep/architecture/issues/52#issuecomment-493652265
where EAT/CWT would be a good fit.

But if OTrP is already deployed (and that means it must not change), I guess my point is moot.

Best regards,
Anders

> 
> 
> Best regards
> Jeremy
> 
>> On 23 May 2019, at 17:53, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>> -------------------------------------------------------------------------
>> CAUTION: This email originated from outside of the organization.
>> -------------------------------------------------------------------------
>>
>> On 2019-05-23 13:53, Hannes Tschofenig wrote:
>>> Hi Carsten,
>>> You have been around when CWT defined but let me provide a history for those who weren't.
>>
>> Couldn't an iteration of
>> https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-03
>> could build on EAT/CWT?
>>
>> Anders
>>
>>> 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.
>>> 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.
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats
>