Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

Laurence Lundblade <lgl@island-resort.com> Tue, 16 October 2018 14:13 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 D5878130DC9 for <eat@ietfa.amsl.com>; Tue, 16 Oct 2018 07:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] 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 E4RY1B9tISXN for <eat@ietfa.amsl.com>; Tue, 16 Oct 2018 07:13:22 -0700 (PDT)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 343F5130DE8 for <eat@ietf.org>; Tue, 16 Oct 2018 07:13:22 -0700 (PDT)
Received: from [172.17.68.162] ([1.22.180.94]) by :SMTPAUTH: with ESMTPSA id CQ5xgqhw2qN9uCQ5zggBZG; Tue, 16 Oct 2018 07:13:21 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <31FD0EA7-8F89-4BF9-81BB-1E6C5CE69DD0@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E71BBBF8-9693-446C-B398-D700C159EE43"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 16 Oct 2018 19:43:12 +0530
In-Reply-To: <9c1cd678-de0f-8a72-5917-3aa23b8a01c4@sit.fraunhofer.de>
Cc: Denis <denis.ietf@free.fr>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
References: <5D773C02-5083-4B10-A705-782E28FD8ADB@island-resort.com> <f84515dd-2e1a-7e66-7c23-b16f8f425d2a@sit.fraunhofer.de> <D7E5069D.C2E65%carl@redhoundsoftware.com> <c72a3b6c-88f2-d452-96be-947a4be1d9c8@free.fr> <73EF502E-B68C-4106-8311-4897B4F2DF8C@qti.qualcomm.com> <b6c9ff4a-cc35-8175-3294-4e6ec366409f@sit.fraunhofer.de> <615BB1D3-29E3-468B-B988-84852F47742C@intel.com> <VI1PR0801MB211230882A5B0D594D66DCFDFAFD0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <b942c7bb-4aad-245f-677a-bbb57b8b26e2@free.fr> <9c1cd678-de0f-8a72-5917-3aa23b8a01c4@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfOSaUTZUPTmgZ2+qGB7e7gyHP2XNc6IQQxtvPM4blkqEkFKg9BdTrsR0TJGBYEJwKxvQCjTh+6TIZBZMb3+6PrW8PYiGVJ9yFfxz6sfGogfJjjIsmf6D Iad9ORbtbReCvWzAuz9nasa7yW1fuJZ5GvpzSO6ejDPljjdvIAYOrC6+D+qFSM4T9chgdnQgIgxyy9D2HNwYimexx43fPCPNoVIAksc1nMoK6xNXgvuoX04+ +jMiCr+fNMXOpRazLHH+kWpagt6FtXPER/lDla3S8UTQAB0vfJH1/rhTC+6Pp635BtVrxac6HHNeOt5zBulqGu2ntm5soYHQQybIXE+aeePUJGtaB/b+DjqV VgtRDSwm+g6Z0Pc111qK3nAMIuljHw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/dvQKJNBsaaU46879OYdjbU7Lwug>
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?
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: Tue, 16 Oct 2018 14:13:27 -0000

Hi Henk,

Appreciate the work you are putting into this.  It is getting closer.

EAT and CWT refer to things like a GPS location, SW version or device debug-enable state as “claims”.  I’m not sure what the equivalent in the current charter is. Grabbing every possible string it could be I came up with this list:

Introduction
"trusted claim sets”
"Attestation Evidence”
"information”
"additional device characteristics”
Problem Statement
"some data”
"the evidence”
“Some data”
Goals
"inter-operable, cross-platform Assertions”
“Assertion"
Deliverables
"Information elements for use in evidence-based attestation”
"CWT claim definitions"


Per previous charter:

Attestation Evidence: Proof for one or more Attestation Claims (characteristics, attributes, ...) that affect device trustworthiness, such as its hardware identity, firmware, software, configuration or composition, compliance status and runtime state. Attestation Evidence may be consolidated through the use of cryptographic hash and key generation algorithms. Attestation Evidence veracity may be augmented by Claimant signatures over portions of the Attestation Evidence. Note that Claims are non-proven assertions as opposed to Attestation Evidence.

So what is the equivalent of a “claim” in this charter?

LL






> On Oct 16, 2018, at 6:41 PM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; wrote:
> 
> Hi Denis,
> 
> I just pulled in your first proposal as an example in paragraph five.
> 
> I am a bit concerned to drop the intent of establishing a believable context about attestation provenance. As you referred, for example, to FIDO - I think that is the intent there, is it not? Laurence proposed the terms "provenance and characteristics" as high level terms and all proponents agreed to use these. If this is a relevant disabler for a specific usage scenario, we might have to reconsider that.
> 
> We cut out differentiating simple cases and more complex cases to reduce the complexity of the charter text for now. If that is counterproductive, we would like to get more input on that, please.
> 
> Viele Grüße,
> 
> Henk
> 
> On 10/15/2018 09:30 PM, Denis wrote:
>>> Here are my 5 cents on the term 'identity'.
>>> 
>>> I have been working on identity management for many years (partially because of my OAuth co-chair role) and I have noticed that the use of the term "identity" tends to confuse more than it helps (even more so when the term is applied to devices and software rather than humans).
>>> 
>>> I believe we could get away with describing what we want without ever using the term.
>>> 
>>> In this context I would argue that we are about identifying different components, such as hardware and software.
>>> 
>>> Ciao
>>> Hannes
>> +1
>> The single sentence where currently the word "identity" is being used is:
>>    As a result, in 2018, a Relying Party would be unable to tell if a
>>    device is trying to mimic the identity of another device or some of
>>    its characteristics.
>> This could be rephrased as:
>>    As a result, in 2018, there is no common way allowing Relying
>>    Parties to tell if some data originates from a trustworthy device
>>    designed to support a specific set of operations/functionalities or
>>    not .
>> The text currently states:
>>    2) In 2018, there are no common, standard ways for Relying Parties
>>    to know the provenance and characteristics of a device
>>    (e.g., an end-user device, platform or endpoint, servers, IoT
>>    devices, device subsystems and sub-modules) that may be requesting
>>    services.
>> As already said on this list, knowing the provenance of a device is not always necessary (but may be useful in some cases).
>> The key point is to know the characteristics of the device.
>> This could be rephrased as:
>>    2) In 2018, there are no common, standard ways for Relying Parties
>>    to know the characteristics of a device (e.g., an end-user device,
>>    platform or endpoint,
>>    servers, IoT devices, device subsystems and sub-modules) that may be
>>    requesting services.
>> Probably a typo in the following sentence:
>>    (1) A standardized way to establish a sufficient level of confidence
>>    that some data originates from a trustworthy device (e.g.,
>>    platforms, servers,
>>    user endpoints, IoT devices, device subsystems or subcomponents)
>>    designed to support a specific set of operations/functionalities /a
>>    communication partner is a trustworthy endpoint./
>> The end of the sentence (i.e. "a communication partner is a trustworthy endpoint.") looks odd and should probably be deleted.
>> The goals are currently limited to the definition of the content of the Assertions. A key point is the way to verify/validate an Attestation.
>> The more complex is the content of an Attestation, the more complex it will be to validate it by a RP.
>> A framework for validating the Attestations should also be part of the charter.
>> Denis
>> Note:At this stage, I still see no text to address both simple cases (e.g. FIDO attestations) and more complex cases.
>>> -----Original Message-----
>>> From: EAT<eat-bounces@ietf.org>;  On Behalf Of Smith, Ned
>>> Sent: Monday, October 15, 2018 9:00 AM
>>> To: Henk Birkholz<henk.birkholz@sit.fraunhofer.de>;rats@ietf.org; Jeremy O'Donoghue<jodonogh@qti.qualcomm.com>;; Denis<denis.ietf@free.fr>;
>>> Cc:eat@ietf.org
>>> Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?
>>> 
>>> I agree with Henk's observation that there is opportunity to find common ground on identity as identity can be a collection of attributes, that if signed, becomes a set of verifiable claims (about identity attributes). Attestation has a similar structure in that it consists of a set of attributes, that if signed becomes a set of verifiable claims. The main difference between identity and attestation attributes is whether the attribute semantically relate to trust (vs. identity). For example, claims of security certification compliance resonates as attestation.
>>> 
>>> It may be possible to combine a set of attestation attributes in such a way that the combination uniquely identifies an entity. But that doesn't make it an identity system per se and shouldn't cause a conflict in charter goals with respect to other identity focused efforts in IETF.
>>> 
>>> Also, inclusion of attributes that don't have semantics that reasonably relate to trust should not be of interest to a working group focused on attestation.
>>> 
>>> -Ned
>>> 
>>> On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz"<eat-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de>;  wrote:
>>> 
>>>     Hi Jeremy & Denis,
>>> 
>>>     all these points of view have merit, I think.
>>> 
>>>     Please have a look at these quotes:
>>> 
>>>     > knowing the provenance of the device
>>> 
>>>     > having the entity creator/manufacturer provide a set of claims which can be verified
>>> 
>>>     > to know the characteristics of a device by issuing to the device a public key certificate which will only be issued to the device if it fulfills an expected set of functionalities.
>>> 
>>>     To me, these descriptions seem to have different intents, scope or
>>>     audience and require most certainly different work-flows, but
>>>     semantically and in consequence representation-wise they also seem quite
>>>     related.
>>> 
>>>     If you think of an identity document as a set of claims (potentially
>>>     including a public key), that is signed and that can match one or more
>>>     things, maybe all three types highlighted above are actually covered by
>>>     the same identity document concept?
>>> 
>>>     With respect to identity documents, I think it is safe so say that we
>>>     can find common ground here rather easily. That said, the way how these
>>>     identity documents come into existence, when and how they are deployed
>>>     on the thing or associated with multiple things is another question. We
>>>     most certainly do not want to end up with a "signing fool" that does not
>>>     add value to the level of confidence (I am quoting Ned Smith here).
>>> 
>>>     This has to be fleshed out explicitly for each scenario and the parts
>>>     that are reused in every scenario should get special attention in the
>>>     upcoming RATS architecture draft.
>>> 
>>>     Identifying claims aggregated in an identity document most certainly can
>>>     include device characteristics, public key(s), or claims about the
>>>     intended functions and capabilities of the thing. Claims can even
>>>     originate from Claimants that are not the thing itself, but external
>>>     entities providing an assertion (e.g. these things are CC-certified).
>>> 
>>>     All different composites of identifying claims have a specific shared
>>>     intend in this context though, I think: expressing Attestation
>>>     Provenance (again - one for one or more things of the same kind). And
>>>     all of them originate from Claimants and therefore use a root of trust
>>>     of measurement, I think.
>>> 
>>>     That said, establishing trustworthy knowledge about attestation
>>>     provenance is only the first step and provides the foundation for more
>>>     complex attestation procedures. In any case, this seem to be required by
>>>     every scenario that was highlighted so far and therefore will most
>>>     certainly be covered in a deliverable.
>>> 
>>>     IHTH,
>>> 
>>>     Henk
>>> 
>>> 
>>>     On 10/15/2018 12:22 PM, Jeremy O'Donoghue wrote:
>>>     > On 12 Oct 2018, at 14:33, Denis<denis.ietf@free.fr >  <mailto:denis.ietf@free.fr>> wrote:
>>>     >> The "Problem Statement" continues as follows:
>>>     >>
>>>     >> (2) Today, there is no common, standard way for Relying Parties to
>>>     >> know the provenance and characteristics of a device (e.g., an end-user
>>>     >> device,
>>>     >> platform or endpoint, servers, IoT devices, device subsystems and
>>>     >> sub-modules) that may be requesting services.
>>>     >>
>>>     >> Knowing the provenance of the device is not always necessary. What is
>>>     >> important is to know that a specific set of functions is (securely)
>>>     >> supported by the device.
>>>     >> There already exists a common way to know the characteristics of a
>>>     >> device by issuing to the device a public key certificate which will
>>>     >> only be issued to the device
>>>     >> if it fulfills an expected set of functionalities. In such a case a
>>>     >> syntax for a trusted claim sets**is not needed.
>>>     >>
>>>     > This is indeed a possible way to address the problem, but suffers from
>>>     > challenges which come down to:
>>>     >
>>>     > - Who issues such certificates. An option is that there is some form of
>>>     > security certification behind this issuance otherwise it is of very
>>>     > limited value.
>>>     > - In order to capture the wide variety of different devices (I prefer
>>>     > "entity" here as it is more general than "device"), many different forms
>>>     > of such certificates would be required. This ends up being much the same
>>>     > thing as a set of claims.
>>>     >
>>>     > Given the multiplicity of entities for which attestation might be
>>>     > useful, it seems to me that having the entity creator/manufacturer
>>>     > provide a set of claims which can be verified is more flexible than
>>>     > requiring a certificate. It seems likely to me that where a formal
>>>     > security certification is needed there will be a certificate issued by
>>>     > the Certifying Body as one of the claims about an entity, but I can
>>>     > think of many cases (supply chain management, to take just one example)
>>>     > where provenance is by far the most useful information.
>>>     >
>>>     > I'm not in favour of changes to the charter in this direction.
>>>     >>
>>>     >> The simplest cases should also be part of the framework.
>>>     >>
>>>     >> Note: I personally appreciate that privacy is an aspect that
>>>     >> will/should be taken into consideration.
>>>     >>
>>>     >> Denis
>>>     >>
>>>     >>> As with the earlier draft, there are many references to verify and
>>>     >>> verifier in the lead up to the deliverable but no deliverables describing
>>>     >>> verification rules. I'd like to see rules in one of these documents and
>>>     >>> think it worth citing in the deliverables. Are bindings to certificate
>>>     >>> management protocols out of scope?
>>>     >>>
>>>     >>> On 10/11/18, 9:49 AM, "RATS on behalf of Henk Birkholz"
>>>     >>><rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de>;   wrote:
>>>     >>>
>>>     >>>> Hi all,
>>>     >>>>
>>>     >>>> sorry for the delay. Please find an updated charter proposal here:
>>>     >>>>
>>>     >>>>>https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md
>>>     >>>> The BoF proponents tried to merge all comments and proposals on
>>>     >>>> keystores, existing solutions, provenance & device characteristics, etc
>>>     >>>> that were raised on the list - and align them in homogeneous fashion.
>>>     >>>>
>>>     >>>> This draft is intended to focus the discussion and improve the wording.
>>>     >>>>
>>>     >>>> Viele Grüße,
>>>     >>>>
>>>     >>>> Henk
>>>     >>>>
>>>     >>>> On 10/06/2018 08:23 AM, Laurence Lundblade wrote:
>>>     >>>>> Hi Henk,
>>>     >>>>>
>>>     >>>>> Bangkok IETF is getting close, will you be able to update the charter
>>>     >>>>> for the attestation BoF to properly include EAT?  I sent you some text
>>>     >>>>> that just needs to be pasted along with some comments. It doesn’t look
>>>     >>>>> like there’s been any updates.
>>>     >>>>>
>>>     >>>>> LL
>>>     >>>>>
>>>     >>>> _______________________________________________
>>>     >>>> RATS mailing list
>>>     >>>>RATS@ietf.org
>>>     >>>>https://www.ietf.org/mailman/listinfo/rats
>>>     >>> _______________________________________________
>>>     >>> EAT mailing list
>>>     >>>EAT@ietf.org
>>>     >>>https://www.ietf.org/mailman/listinfo/eat
>>>     >>
>>>     >>
>>>     >> _______________________________________________
>>>     >> EAT mailing list
>>>     >>EAT@ietf.org  <mailto:EAT@ietf.org>
>>>     >>https://www.ietf.org/mailman/listinfo/eat
>>>     >
>>>     >
>>>     >
>>>     > _______________________________________________
>>>     > EAT mailing list
>>>     >EAT@ietf.org
>>>     >https://www.ietf.org/mailman/listinfo/eat
>>>     >
>>> 
>>>     _______________________________________________
>>>     EAT mailing list
>>>     EAT@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/eat
>>> 
>>> 
>>> _______________________________________________
>>> EAT mailing list
>>> EAT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eat
>>> 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.
> 
> _______________________________________________
> EAT mailing list
> EAT@ietf.org
> https://www.ietf.org/mailman/listinfo/eat