Re: [EAT] Naming (was Re: Scope, Goals & Background for RATS)

Laurence Lundblade <lgl@island-resort.com> Wed, 26 September 2018 20:07 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8214B1286D9 for <eat@ietfa.amsl.com>; Wed, 26 Sep 2018 13:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 DDKkys6Z9laJ for <eat@ietfa.amsl.com>; Wed, 26 Sep 2018 13:07:08 -0700 (PDT)
Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.104]) (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 B2612126CC7 for <eat@ietf.org>; Wed, 26 Sep 2018 13:07:08 -0700 (PDT)
Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 5G5Tg9i0jMXah5G5TgQfUi; Wed, 26 Sep 2018 13:07:08 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <875D8B0B-802F-4FA1-B4AD-07B9A710CB5C@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A905A007-2506-42C5-AF06-3070F0E7001A"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Wed, 26 Sep 2018 13:07:07 -0700
In-Reply-To: <9D0BEEB9-B725-40B6-8848-555B56CB61D1@telefonica.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
To: "Diego R. Lopez" <diego.r.lopez@telefonica.com>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <000D27F1-C5C0-4F14-A628-42A321077A52@island-resort.com> <53CD22A1-DFD2-48DA-8668-2744CCDB6BD5@telefonica.com> <07ADA0A9-DDF6-4B32-BE45-A99A2587DC16@island-resort.com> <9D0BEEB9-B725-40B6-8848-555B56CB61D1@telefonica.com>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfIuFAZoT02e+t+NSujnBBxWUnSZh9s5f57WXYQQNdXtna0cTh0BNwrE8HO2aH/WYvGvSnWQIV0Jjjh/FOo62HGIhRlCTUREu/rK7Da8V0cwXnM+OuWHY CCQIf1N6qtFPXf/PBIG6QAdexIwm+djIpBmLREjpQOBUvA1MYgHgrC8r0KWo6G/q1rLIx0dqWyWgdBMCgAJgUisYmwpNUdCw+p2aoVhj5WCDaRfETWULp7Sk x76mH2A8pOjVl1q8Y73/VrtatXwpv/hV9iyOa+zuUto=
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/IjLuRAI4xPeIY4aje5XceiR0ock>
Subject: Re: [EAT] Naming (was Re: Scope, Goals & Background for RATS)
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 20:07:12 -0000

Either way is good for me. Like either a lot. Figured CREAT was OK because the UNIX system call (“man 2 creat; friend of open) left off the “e” too.

LL


> On Sep 25, 2018, at 2:35 PM, Diego R. Lopez <diego.r.lopez@telefonica.com> wrote:
> 
> What if we add an E at the end (that could fit as “Enhancements”)?
>  
> --
> "Esta vez no fallaremos, Doctor Infierno"
>  
> Dr Diego R. Lopez
> Telefonica I+D
> https://www.linkedin.com/in/dr2lopez/ <https://www.linkedin.com/in/dr2lopez/> 
>  
> e-mail: diego.r.lopez@telefonica.com <mailto:diego.r.lopez@telefonica.com>
> Tel:         +34 913 129 041
> Mobile:  +34 682 051 091
> ----------------------------------
>  
> On 25/09/2018, 20:10, "Laurence Lundblade" <lgl@island-resort.com <mailto:lgl@island-resort.com>> wrote:
>  
> One more attempt: CREAT — Common Remote Entity Attestation Technology
>  
> LL
>  
> 
> 
>> On Sep 20, 2018, at 3:27 PM, Diego R. Lopez <diego.r.lopez@telefonica.com <mailto:diego.r.lopez@telefonica.com>> wrote:
>>  
>> Hi,
>>  
>> I agree with you in the fact that the proposal is intended to address the proposed EAT work, and I think we agree in that this is a good way to go. Regarding the name, and given my dislike for cats, I’d propose to use CRAT, as in aristo-crat or demo-crat… (coming from the Greek god of strength and power)
>>  
>> And I tend to agree in your two final comments on public key, and the fact that circumscribing attestation to devices (of any nature, physical or virtual) need to be clearly stated.
>>  
>> Be goode,
>>  
>> --
>> "Esta vez no fallaremos, Doctor Infierno"
>>  
>> Dr Diego R. Lopez
>> Telefonica I+D
>> https://www.linkedin.com/in/dr2lopez/ <https://www.linkedin.com/in/dr2lopez/> 
>>  
>> e-mail: diego.r.lopez@telefonica.com <mailto:diego.r.lopez@telefonica.com>
>> Tel:         +34 913 129 041
>> Mobile:  +34 682 051 091
>> ----------------------------------
>>  
>> On 20/09/2018, 16:18, "EAT on behalf of Laurence Lundblade" <eat-bounces@ietf.org <mailto:eat-bounces@ietf.org> on behalf of lgl@island-resort.com <mailto:lgl@island-resort.com>> wrote:
>>  
>> It’s a bit buried, but I see you do intend that this include the EAT work. Thus the work would not be TPM/TCG centric. It would include use cases like FIDO and Android Keystore attestation that are often based on TrustZone. It could also include EPID-related use cases. Please confirm. 
>>  
>> My preference would be to choose another name for the group that is neither EAT or RATS to help make this clear. I don’t really think there is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a name. My suggestions are “RA” for Remote Attestation or “CAT” for Common Attestation Technology (and besides cats caused us to invent the Internet so we share pictures of them (securely)). 
>>  
>> I propose a more high-level intro with examples:
>>  
>>> The purpose of RA/CAT is to allow a Relying Party (e.g. a web service, network management center...) to securely receive Claims from an Entity requesting service (e.g. a phone, router, IoT device...) that allow the Relying Party to determine if and how that entity is trusted.  For example:
>> o    An IoT management back-end receives a signed nonce that proves the IoT device is the genuine article manufactured by the expected OEM and is not a Linux box or such emulating such a device.
>> o    A network management center receives a set of measurement claims from a router to know that the configuration has not been tampered with.
>> o    An online banking service receives many claims about the device including location, SW versions and measurements and determines that it will allow a higher-than-usual value transaction.
>> o    A government online document server receives claims indicating manufacture and location of the device, determines they are from the correct country and grants access to classified documents.
>>> There are protocols for determining and securing the identity of a server or service (TLS and IPsec). There are many protocols for authenticating end users (SASL, TLS client auth, EAP…). There are no general protocols for managing the characteristics, security and identity of an end client device (an Entity). RA/CAT aims to address that gap. 
>>>  
>>> There is no goal here to set criteria for what is trustworthy or not as that is an impossible task as it will vary widely from use case to use case. The goal here is to securely provide information (Claims) to the Relying Party so it can make that determination based on its own criteria and needs.
>>  
>>  
>> I don’t think the intro should mention public key crypto. I know of attestation solutions that do not use it.
>>  
>> I tend to prefer “attestation” when the goal is whether and how a device is to be trusted and “authentication” when the goal is how a human is to be identified. FIDO, OAuth, SASL are all about users and use the word authentication. 
>>  
>> LL
>>  
>> 
>> 
>> 
>>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
>>>  
>>> Hi all,
>>> 
>>> we pushed an initial document to the RATS github in order to focus the discussion about remote attestation procedures a bit.
>>> 
>>> 
>>> 
>>>> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md <https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter..md>
>>> We included a background section to better highlight the meaning of the term "attestation" in general. Hence, there is a trade-off between clarity and conciseness, which is one of the things we would like to get feedback about.
>>> 
>>> Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> EAT mailing list
>>> EAT@ietf.org <mailto:EAT@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
>>  
>>  
>> 
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>> 
>> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>> 
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> 
>  
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição