Re: [Danish] Charter Text and the Problem Statement
Ash Wilson <ash.wilson@valimail.com> Wed, 16 June 2021 21:28 UTC
Return-Path: <ash.wilson@valimail.com>
X-Original-To: danish@ietfa.amsl.com
Delivered-To: danish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0E23A2703 for <danish@ietfa.amsl.com>; Wed, 16 Jun 2021 14:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 RYR33yao9Yr9 for <danish@ietfa.amsl.com>; Wed, 16 Jun 2021 14:28:01 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4BE093A1CA4 for <danish@ietf.org>; Wed, 16 Jun 2021 14:28:01 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id z4so3096005qts.4 for <danish@ietf.org>; Wed, 16 Jun 2021 14:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nEAghKixQ040zj+NEelYzBSd0tkgLmn8iWyw7WbPCPU=; b=fqUXLYqBF6JyBELKrzEd7bWI7lSxqd/H6WSyybRHxfFK1HWXN3HcjDkAkRJGEfDFGC BuC1SPJWkMmEDb+gThwi1V5p6AuEncnmzwJh6lglUXQ1N/juzZpKvgAns3lK+wwjUi6P xjXEj/68u4wvVOp1SPWnYNZZxJsKR32c7f/TQ04QVYqJtdmqNah8H3U9v5U/V9bjpmaf se8WBYVJDcgPqpoZQ0bD8tpNESs7e2UNJPkGTvXLqlrXFgsRTpKCJ5QV97Fmug2sXvjY IKjs5Zi0iTMC+9rT24wPQlM/gbFGjHEW5N+9iyKvVysdnPwoxDqhJ0Xc7s4zZfCFr5S1 v5ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nEAghKixQ040zj+NEelYzBSd0tkgLmn8iWyw7WbPCPU=; b=m+63ijWiOT5gvpXHMfTR76phEZTb6e21Z6bw+yd7IKNpEt/oAA7SLWg+JKSmfPLyM/ kghzFr6PaEpmAD1zGITjwHi/tYFNb3BgQRvy3yMhZplthWbmYyy2orW2cIstZxIhiRDH Y9/rxDzmXo+fV4NV19qAOPBU0kUgCTyYgMYETtwY7LxACvi5X2SBvisQO7xkGc3E0VEX BN4o/1mgidLVBOEBXv+Vc6lNcukqtt9zzOPS7bQ+WnahQxt2wf0Euk7Xm3wR0CK9Ql5r VCwnxHmfdU9Of4DnF5zjoW2Tx6TQB7uWN0zHFKMTvRZ4YR/dDwJyQYffHcRlFnpZ8HkH JWyQ==
X-Gm-Message-State: AOAM531VZrYupt2SkwPXT23x4Zh6M9atW1cC2Pqe1B9JVplAp2tri1iw dr1yL7y+YsX5dmdsuPUUEJ9bRVA1EI+mvid4wv8nvg==
X-Google-Smtp-Source: ABdhPJyLJQFYLwKEPOK7y5qDitNj33mY5UNI68sxTUlmoQckqL2Ekv7Xd4ZIJxS5ryssxtvl/D8T1P9c5SIBz0QpfrM=
X-Received: by 2002:aed:30cd:: with SMTP id 71mr1825232qtf.31.1623878878955; Wed, 16 Jun 2021 14:27:58 -0700 (PDT)
MIME-Version: 1.0
References: <DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9@DBBPR08MB5915.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB5915066E1CE5BDB2D695A8DAFA0F9@DBBPR08MB5915.eurprd08.prod.outlook.com>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Wed, 16 Jun 2021 14:27:48 -0700
Message-ID: <CAEfM=vQehhvSNeBNitJJjisEbimn_gizoo8VTtHWUJ1zSU+rQg@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "danish@ietf.org" <danish@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd235f05c4e8c375"
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/OkQzlyZoKlEar5-GU6HgtSz3ebY>
Subject: Re: [Danish] Charter Text and the Problem Statement
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DANE AutheNtication for Iot Service Hardening <danish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/danish>, <mailto:danish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/danish/>
List-Post: <mailto:danish@ietf.org>
List-Help: <mailto:danish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/danish>, <mailto:danish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2021 21:28:08 -0000
Hi Hannes, Thanks for the questions, and apologies for keeping you waiting on answers/clarification. On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > I have been reading through the charter text in an attempt to understand > the problem statement. > > > > Two problems are mentioned: > > > > 1) Challenges with naming collisions in the IoT space. > > > > 2) Credential issuance is time consuming. > > > > Ad 1: Reading through the text it feels like naming collisions are a big thing in IoT. I have not heard about those problems. Could you elaborate? > > Certainly. I'll use a hospital as an example environment. Within a hospital, it is desirable to implement 802.1x authentication using EAP-TLS for access to protected networks. EAP-TLS enables the use of PKI-based identity to authenticate an entity for network access. When implementing EAP-TLS for network access, RADIUS is a common protocol/server used for authentication behind the switch or wireless access point. Guidance for configuring RADIUS recommends the use of only one CA certificate for authenticating supplicant certificates. This guidance can be found in the wild in Freeradius configuration files for EAP-TLS, related to the 'ca_file' configuration directive. CAs guarantee the uniqueness of an entity's name within the scope of the CA, but have no method for enforcing name uniqueness across other CAs. For instance, CA1 and CA2 may both sign certificates for entities with the same name. If CA1 and CA2 are both trusted by the RADIUS server, and two entities named "medicaldevice123" exist, one per CA, then the resulting ambiguity makes it difficult to appropriately apply access controls. This ambiguity is mitigated by operating a single organizational PKI, and requiring identities issued by that single organizational PKI for EAP-TLS authentication. Onboarding devices to organizational PKI requires time and effort. Oftentimes some sort of skilled labor and/or dedicated infrastructure for automating the onboarding process is involved. DANE allows us to bind a DNS name to a public key, and mitigates the ambiguities introduced by the use of multiple CAs. An organization can only issue working identities within its own namespace in DNS. Since naming ambiguity can be mitigated using DANE, we may now choose to use manufacturer-issued PKI, represented in DNS, for authenticating entities. >From the hospital's standpoint, the IT staff no longer needs to manage the process of onboarding devices to organizational PKI. The device arrives on-site with an identity which can be immediately used for network authentication. > You add that “In response to the challenges related to > > ambiguity between identities issued by different CAs, application owners > > frequently choose to onboard IoT devices to a single CA.”. Is that a good or a bad development? > > It is a good development if the organization really wants to directly manage all of the credentials for all of the application participants. The effort and rationale behind BRSKI (RFC 8995) suggests a desire to make onboarding to organizational PKI easier to automate. If a supplier issues a trustworthy identity for a device, and DNS prevents another PKI from issuing working credentials under the same name, then issuing another identity via organizational PKI becomes superfluous. This is where we think that time and effort can be saved, because the skills required for onboarding do not need to include the management and issuance of identities under organizational PKI. > > > Ad 2: Is it really true that credential issuance is time consuming? Why is > that? For whom is it time consuming? > Credential issuance very often requires the device and the person bootstrapping the identity to be in the same place. Some platforms and protocols exist to make that process easier (like BRSKI) or less human-involving. The time investment seems to be on the part of both the manufacturer (in issuing the IDevID) as well as the organizational IT staff, who manage the organizational PKI. > > > Ciao > > Hannes > > > > PS: You use the term “Certificate Authority (CA)”. It is actually called > “Certification Authority”. > > > > > 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. > -- > Danish mailing list > Danish@ietf.org > https://www.ietf.org/mailman/listinfo/danish > -- *Ash Wilson* | Technical Director *e:* ash.wilson@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
- [Danish] Charter Text and the Problem Statement Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Ash Wilson
- Re: [Danish] Charter Text and the Problem Stateme… Viktor Dukhovni
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Wes Hardaker
- Re: [Danish] Charter Text and the Problem Stateme… Ash Wilson
- Re: [Danish] Charter Text and the Problem Stateme… Viktor Dukhovni
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Michael Richardson
- Re: [Danish] Charter Text and the Problem Stateme… Ash Wilson
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Wes Hardaker
- Re: [Danish] Charter Text and the Problem Stateme… Wes Hardaker
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Michael Richardson
- Re: [Danish] Charter Text and the Problem Stateme… Michael Richardson
- Re: [Danish] Charter Text and the Problem Stateme… Wes Hardaker
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Michael Richardson
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Viktor Dukhovni
- Re: [Danish] Charter Text and the Problem Stateme… Hannes Tschofenig
- Re: [Danish] Charter Text and the Problem Stateme… Viktor Dukhovni
- Re: [Danish] Charter Text and the Problem Stateme… Michael Richardson