[EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

Laurence Lundblade <lgl@island-resort.com> Thu, 20 September 2018 21:29 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 3D088130E4E for <eat@ietfa.amsl.com>; Thu, 20 Sep 2018 14:29:52 -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 Td62ZuA1pAS5 for <eat@ietfa.amsl.com>; Thu, 20 Sep 2018 14:29:50 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 5B3A7130E35 for <eat@ietf.org>; Thu, 20 Sep 2018 14:29:48 -0700 (PDT)
Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 36WBggVXA1PTa36WBgc6GE; Thu, 20 Sep 2018 14:29:47 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <7E4B881E-7AD6-42A1-B2B3-7478DFCCB9FB@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_868A5EB7-4716-4B0A-88CC-AAD84B073B63"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 20 Sep 2018 14:29:47 -0700
In-Reply-To: <67234e9e-1543-5ecb-7fd8-3797d529744c@free.fr>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, eat@ietf.org, rats@ietf.org
To: Denis <denis.ietf@free.fr>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr> <17ba2709-0a0e-859f-2fa2-fd09747273d9@sit.fraunhofer.de> <67234e9e-1543-5ecb-7fd8-3797d529744c@free.fr>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfNeO+JeLMv/14RxLRm1MD8ZLrdFwWDQ2o5cLyx4y+bu6f4WV1JA+Rnd9O+kM3FTZmRFgOv4use7yaL1xk40WXVhzUUDjUM/5SQVzZDIMjSH+AgnpcQLp H+Z7NUswuEe4dxFyrZcEaBFzVmkj2RpN6hykGOnWhTAoRAKD/ofIGkdzHw4cPhtsatj5NyK7IO7lMJ4v6nYeWmrEtRtokUDLnnWTrnYdYBmQ14kfGSp6AzeN jfogJOejLDz2cbE6nEgll8qeQIAFv9GAkitD+h99V+E=
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/6Z7pdWB1cHawR2KDmz8pqNhCE0Q>
Subject: [EAT] Implicit vs Explicit Attestation (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: Thu, 20 Sep 2018 21:29:52 -0000

Forking the discussion here to focus on implicit/explicit attestation. That seems to be a new term invented in this WG Charter as I haven’t seen it elsewhere. I’m not sure what it means yet. It seems to have something to do with how the loop is closed in the Attestation Model below. In particular the role of the Entity Manufacturer.

The obvious way to do this (kind of like TLS certs, but flipped): 
- The Entity Manufacturer puts a private key + X.509 certificate in each Entity (device) it makes
- This Entity (device) X.509 certificate is signed by the Entity Manufactures Root Key
- The Entity uses its private key to sign some Claims 
- The Entity sends the signed claims and its X.509 cert to the Relying Party
- The Relying Party gets the Entity Manufacturers Root Cert in a one time operation and saves it
- The Relying Party chains the device X.509 per to the Entity Root Cert
- The Relying Party uses the public key in the device X.509 to verify the signature on the Claims

One of my guesses for what implicit attestation is — The RP (Relying Party) does not get any root keys or such from the Entity Manufacturer or a CA or a trusted third party. They verify the signature solely based on what is in the signed token they received. The RP probably did send a nonce and the Entity signed it, so there is proof-of-posession of the Entity's key, but that key and device could be any device so little is proved. The RP can remember the Entity’s key and expect it to be the same next time to give it some value. This is called self-attestation of surrogate attestation in FIDO. It not considered very secure. The loop is not closed. 

Another one of my guesses — The RP does get key material with which to perform verification, but it is not directly from the Entity Manufacturer. Instead there is some CA or trusted 3rd party in the loop. This is a realistic scenario. The loop is closed so it is secure.

I see this as a topic for technical discussion, not something for definite in the charter.

LL





> On Sep 18, 2018, at 8:56 AM, Denis <denis.ietf@free.fr> wrote:
> 
> Hi Henk,
> 
> I fear that we don't understand each other. 
> 
>> Hi Denis, 
>> 
>> there are a lot of topics addressed by your reply. First of all, thank you for the the feedback! 
>> 
>> We attempted to create a document that is as inclusive as possible - within reason. Hence, it is also solution agnostic. 
>> 
>> As Andreas just said, Proof-of-Possession of a secret key is intended to be captured by Implicit Attestation. In other words: 
>> if you are able to use that secret key to sign something, it implies (that is the "implicitness" here) that "that device has some well known properties". 
> 
> No. If you are able to use a secret key to sign something, it does not mean that you are using a device. 
> If a device is able to sign something, it does not necessarily mean that what is signed really comes from the device, unless "that device has some well known properties".   
> 
>> The definition of implicit attestation might require some improvement, I assume (and I don't mean by adding even more words). 
>> 
>> I am a bit confused by the use of "attestation certificate", "private key" and "origin of data exchange" in your reply. 
>> 
>> If "certificate" in your proposal: 
>> 
>>> "shared attestation certificates" to designate attestation certificates that are specific to a batch of devices from the same model (like in FIDO), 
>>> "individual attestation certificates" to designate attestation certificates that are specific to each device. 
>> 
>> means identity document, the concepts of "Singular Identity", "Shared Identity", and "Group Identity" are already subsumed in the IETF by the definition of "Identity" in RFC4949. 
>> Maybe that fact is a little bit too hidden at the end of the Background section that refers to "cryptographic identities". Highlighting that more up front and referencing RFC4949 
>> explicitly could address that issue. 
> 
> It does not mean anything from the above list. My arguments have nothing to do with "Identity". Typically, an Attestation Certificate it is an X509 certificate, as in FIDO.
> 
>> 
>> Correspondingly, the same secret key can be enrolled on multiple devices, but that is not the same thing as enrolling the same (group/shared) identity document on multiple devices. 
> 
> The private key of a device is never enrolled but is placed in the device by the manufacturer of the device (or the entity that personalizes it before making it available to an end-user);
> 
>> 
>> The smallest identity document I can think of would be a signed public key. More commonly today, it would be an ASN.1-based identity document, I assume.
> 
> My arguments are fully unrelated to "identity documents".
> 
>> Jumping a bit to the end: 
>> 
>> Local Attestation is described in the Background section and is referred to again in the Scope section as out-of-scope. 
> 
> This is fine.
> 
>> That said, as Local Attestation can be a prerequisite for Remote Attestation and it also might require some provisioning (via network protocols) in order to work, 
>> provisioning protocols that enable local attestation are currently considered in-scope. 
>> 
>> The fact that the definition of Attestation Evidence is difficult to understand could be the biggest issue here, I think. Especially, because it is the basis for 
>> the definition of Remote Attestation, as you highlighted. I will come back to this topic as soon as I have a few more free cycles :) 
>> 
>> Viele Grüße, 
>> 
>> Henk 
> ...