Re: [Acme] [SUSPICIOUS] Use cases / trust model for device certs

Eliot Lear <lear@cisco.com> Wed, 17 April 2019 18:29 UTC

Return-Path: <lear@cisco.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B9120188 for <acme@ietfa.amsl.com>; Wed, 17 Apr 2019 11:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 v1A9RfAtk6ZB for <acme@ietfa.amsl.com>; Wed, 17 Apr 2019 11:29:06 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55C7120006 for <acme@ietf.org>; Wed, 17 Apr 2019 11:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8491; q=dns/txt; s=iport; t=1555525745; x=1556735345; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=nFlNa0K4YRSv/eZv+NwjD2mBoZtm10clRagn1/8lW6o=; b=Mh0uVJCUk1RLtwh4NcCq6QhvHyCubI6Zjv7hhzl43UeKxg5D1CtzrfBD 3KRT9xDwvGHWwgXqP1In4vpoRd+gE/OpxuM2MiRJ4aBjhSg43kaldDHb0 S+3tY40Wcx1rmgM/PlBrZjyCz5kdOeMuJjJj8vX1nuxfRJe3OCufupy+W 0=;
X-Files: signature.asc : 195
X-IronPort-AV: E=Sophos;i="5.60,362,1549929600"; d="asc'?scan'208,217";a="463017363"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Apr 2019 18:29:05 +0000
Received: from [10.41.32.64] ([10.41.32.64]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3HIT4PO009956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Apr 2019 18:29:04 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <751014AF-51B8-4377-AF1B-EC0FC744AA80@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_932E3CE8-D3F3-4628-8917-57000A6A06E4"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 17 Apr 2019 11:29:02 -0700
In-Reply-To: <CAL02cgT1hY_wm8d0zpa3hpx926B3_of+=cnDEwikMHS90gVyjw@mail.gmail.com>
Cc: IETF ACME <acme@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Owen Friel <ofriel@cisco.com>
To: Richard Barnes <rlb@ipv.sx>
References: <CAL02cgT1hY_wm8d0zpa3hpx926B3_of+=cnDEwikMHS90gVyjw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Outbound-SMTP-Client: 10.41.32.64, [10.41.32.64]
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/CAxnKeanGKwlAqZJY06bYo9h9Vg>
Subject: Re: [Acme] [SUSPICIOUS] Use cases / trust model for device certs
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 18:29:08 -0000

Hi Richard,

Just to add, ACME is really an enrollment protocol.  For device onboarding, we have those.  I hadn’t really thought about ACME as one, but there are definitely some concepts that can and should be leverage.  PoP or Proof of ownership is one that requires exploration.  Also, this ties to supply chain management/SBoM, and the work of SUIT.  Specifically, how does the onboarded identity relate to the application?

There is a mailing list for this: iot-onboarding@ietf.org <mailto:iot-onboarding@ietf.org>.

Eliot

> On 17 Apr 2019, at 10:09, Richard Barnes <rlb@ipv.sx> wrote:
> 
> Hey Rifaat,
> 
> Owen and I were chatting about ACME and device certs this morning, and it seemed like it might be useful to rekindle discussion on the topic here on the ACME list.
> 
> I'd like to push a little more on the trust model here.  Just to establish some terminology:
> 
> - Device: Uses certificates to authenticate identifiers
> - Vendor: Makes the device that will get the end certificate
> - Customer: Buys the device from the vendor and operates it
> - CA: Validates identifiers and issues certificates
> - Relying Party: Uses certificates to verify authentication for identifiers
> - Device Identity: MAC address or similar
> 
> In the flows Owen and I have been discussing (more based on ANIMA/BRSKI), the model is basically broken in two, with the customer in the middle:
> 
> 1. The customer validates devices' device identity as part of the ANIMA flow, based on the customer trusting the vendor, and assigns the device a domain name
> 2. The customer uses ACME to issue domain name certificates (the CA is unaware of the device identity)
> 
> That all pretty much just works with BRSKI and ACME as they are today.  But it presumes that the RP is authenticating the device by domain name, as is prevalent in most uses of TLS today.
> 
> In contrast, it seems like your draft presumes that the RP needs to know the device identity; it's not satisfied by a domain name alone.  Can you elaborate a bit more on what scenarios you have in mind for this?  If all you care about is the customer tracking things, then the model above is sufficient; the customer can simply assign domain names that encode the device identity however it likes.
> 
> Thanks,
> --Richard
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://secure-web.cisco.com/1tlmqIbvXi2GsjydUBbTmsMvgAIUs8PxjTEsHBBrQHvGqLC_eq6oyniVBQXUhbMRIWXPbic_j3yu99L40LmxOHOYbKI4aLWdBh6LaxJPSYilwp4z5jjYm7UPZa8EOAIGFrR9y1rF0w2Ls0JKD9OKvDPF-XGunL6DjYBbJFzon6FcSCWNBEXAMs4i5ieqiAGKlvM-Mbou1gqIVK13Mf-9mlIBvXhq0Kry2Koqd9p67M1NUtZyo8XBseYnMDprATd3AN0j20H5vApQe62q3I36Pyx6Mi69rw_H6vODTiraXAsFI58RFVCsqmTrVa9ZTNVwV/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facme