Re: [Secdispatch] Confusing terminology was Re: [Iot-onboarding] DANE IOT proposed outcome
Eliot Lear <lear@cisco.com> Wed, 18 November 2020 13:03 UTC
Return-Path: <lear@cisco.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8163A187B; Wed, 18 Nov 2020 05:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 xKjLcL3xOkwb; Wed, 18 Nov 2020 05:03:36 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D7C3A1878; Wed, 18 Nov 2020 05:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32625; q=dns/txt; s=iport; t=1605704615; x=1606914215; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=A9pwaR4n7vyV42osomWXNOy9gKav7H2h5eOcLhwZGyE=; b=ahEpEko+BeZZbPpPEoNF+VN6/McgTm1E0vxP6Ici+u8fDvR9GAEg1T60 VPmAt6IgRn1bm9f5SON0ONb99r18SIeUSkY3JHcf7uXeKs25qU00IXhZQ ebexhlN976mOKr54IxCl91jXPggt6PeGYS8k4bkkEBAIE55u8+Q4R48aF o=;
X-Files: signature.asc : 488
X-IPAS-Result: A0BwAABtGrVf/xbLJq1ZCRoBAQEBAQEBAQEBAwEBAQESAQEBAQICAQEBAYIPgSOBB3RVATIuhD2JBYd9JoEFhmWSXIFoBAcBAQEKAwEBGAEKDAQBAYQGRAKCJiY4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBAQIBAQEhSwsFCwsRBAEBASABBgMCAicfCQgGExsEgmQCIQGCZiAPrgx2gTKFV4RmCgaBOIFTjAiCAIERJwwQghoFMD6CXQEBAoEoAQgKAQlOgmEzgiwEkEGKbIEam26Cd4McgTeWRgMfoXqwRoNkAgQGBQIVgWsjZ3AzGggbFTsqAYI+PhIZDY0pgQIXFIhOhUVAAzACAQEzAgYBCQEBAwmOSAEB
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,486,1596499200"; d="asc'?scan'208,217";a="31220990"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2020 13:03:33 +0000
Received: from dhcp-10-61-101-123.cisco.com (dhcp-10-61-101-123.cisco.com [10.61.101.123]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AID3V8J000781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Nov 2020 13:03:32 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <27155BC8-36F3-48D4-8483-63E58ED0F524@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A8FAEBE5-FD39-46EE-833C-7A00506B26DF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 18 Nov 2020 14:03:30 +0100
In-Reply-To: <184ad9b2-fcee-ad01-5fe2-338ad3dcd65a@ericsson.com>
Cc: "Panwei (William)" <william.panwei@huawei.com>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
To: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <b178d5066d6b4371a59ffe59bb6d6447@huawei.com> <A8214369-216E-440B-8757-172416CDF02B@cisco.com> <184ad9b2-fcee-ad01-5fe2-338ad3dcd65a@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Outbound-SMTP-Client: 10.61.101.123, dhcp-10-61-101-123.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/zuLT4U1x5GZAxXMi1TkSrPMDdvE>
Subject: Re: [Secdispatch] Confusing terminology was Re: [Iot-onboarding] DANE IOT proposed outcome
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 13:03:38 -0000
Hi Mohit, Your confusion is entirely understandable. There the term means different things at different layers at this point. Let me clarify: In the general context, a peer is the other side of a connection. In the EAP case, it’s the end device looking to be authenticated by an authenticator. I think both uses are in context for this discussion… sadly. Eliot > On 18 Nov 2020, at 13:10, Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org <mailto:mohit.m.sethi=40ericsson.com@dmarc.ietf.org>> wrote: > > Hi Eliot, > > I find your use of the term peer confusing. Let me explain what I mean with this table on various terms for an EAP-TLS implementation: > > >> +-------------+---------------+-----------------+-------------------+ >> | | Device | Gateway | Server | >> +-------------+---------------+-----------------+-------------------+ >> | TLS | Client | | Server | >> | | | | | >> | EAP/AAA | Peer | Authenticator | EAP server/backend| >> | | | | auth server | >> | | | | | >> | 802.1x | Supplicant | Authenticator | Authentication | >> | | | | server (AS) | >> | | | | | >> | RADIUS | | Network access | RADIUS server | >> | | | server (NAS) | | >> | | | | | >> | 802.11 | Station | Access Point | | >> +-------------+---------------+-----------------+-------------------+ > > Assuming email clients are able to render this ascii table correctly, I hope you understand that in some contexts, the device is the peer. When you say proving peer to device, and device to peer, I am unsure if you are referring to a server or a smartphone that acts as a companion device during bootstrapping. > > I don't want to be the terminology police here asking people to be more cautious with the usage of terms. I also understand the reality that companies are often forced to do branding to look cool and perhaps improve chances of adoption. > > Maybe as protocol engineers we can do somewhat better? I thought we already had too many terms for device: station/peer/client/supplicant. And then I saw the term pledge. Good luck trying to teach network security to new folks. No wonder many students I encounter now want to do AI or javascript but not low-level protocols. I am similarly not enthusiastic with usage of loose terms such as onboarding. At least in my study of several different systems including bluetooth/wi-fi/LWM2M: they principally follow the same terminology pattern: bootstrapping and authentication followed by provisioning/configuration. You could point me to OCF which uses onboarding but we don't have to make the same mistakes as another SDO. > > --Mohit > > On 11/16/20 2:50 PM, Eliot Lear wrote: >> Hi Wei Pan, >> >> I agree with you that there is a need for something that doesn’t require devices to have a full PKI built in. But there needs to be something unique about the device that it can express and prove. Also, we should separate out two problems: >> >> Proving the peer to the device >> Providing the device to the peer >> >> Each has slightly different characteristics, especially when it comes to certificates. Nobody should expect a huge cert store to be on a light weight client. As was said in the chat, that is one thing that BRSKI solves. But DPP/POK also solves it without certificates, but still requires at least a public/private key pair. Less than that I do not know how to work the problem. >> >> Eliot >> >>> On 16 Nov 2020, at 13:02, Panwei (William) <william.panwei@huawei.com <mailto:william.panwei@huawei.com>> wrote: >>> >>> Thanks to Eliot for summarizing these. >>> >>> I think the core concept of using DANE in IoT scenario is to get rid of certificates and PKIX. The solution of how to securely onboard the IoT devices and allocate the DNS domain name, both with and without initial certificates, is the key part to figure out. >>> If the IoT devices have no initial certificates, such as 802.1AR IDevID certificate, as their initial identity, then the BRSKI mechanism won’t be appropriate for these devices because BRSKI has a requirement of IDevID. >>> If the IoT devices have an IDevID certificate, I think it can still use BRSKI to onboard, but it won’t use EST to request a certificate any more, instead, it will apply for a DNS domain name by using some protocols. >>> >>> That’s my preliminary thoughts, maybe not right. >>> >>> Regards & Thanks! >>> Wei Pan >>> >>> From: Secdispatch [mailto:secdispatch-bounces@ietf.org <mailto:secdispatch-bounces@ietf.org>] On Behalf Of Eliot Lear >>> Sent: Monday, November 16, 2020 6:55 PM >>> To: secdispatch@ietf.org <mailto:secdispatch@ietf.org> >>> Subject: [Secdispatch] DANE IOT proposed outcome >>> >>> Thanks to Shumon for presenting the DANE use case for IOT. >>> >>> We discussed taking this to the iot-onboarding@ietf.org <mailto:iot-onboarding@ietf.org> list as there were a number of rather big open issues that people wanted to discuss. >>> >>> We also discussed a non-WG forming BOF to look at, as Ted put it, the broader context for onboarding. To give people a feel for the sort of related work that is available, here are a list of related activities: >>> >>> draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a request/response mechanism that uses RFC 8366 vouchers to introduce devices and network infrastructure. >>> Intel’s SDO provides an application level introduction using vouchers as well. This work has been taken up by the FIDO alliance. >>> The Wifi Alliance has Device Provisioning Protocol (DPP) which does not attach to a global name space prior to provisioning having occurred, but does represent a minimum case (just public keys). >>> draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for wired use, where DPP is focused on 802.11 networks. >>> There are a number of BRSKI related drafts by Owen as well, relating to cloud-based registrars. >>> There is also work by Michael Richardson and Peter Van Der Stock on constrained vouchers. That work is taking place in ACE. >>> >>> Understanding the landscape might help us understand where DANE fits in. >>> >>> Regards, >>> >>> Eliot >>> -- >>> Iot-onboarding mailing list >>> Iot-onboarding@ietf.org <mailto:Iot-onboarding@ietf.org> >>> https://www.ietf.org/mailman/listinfo/iot-onboarding <https://www.ietf.org/mailman/listinfo/iot-onboarding> >> >> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org <mailto:Secdispatch@ietf.org> >> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>
- [Secdispatch] DANE IOT proposed outcome Eliot Lear
- Re: [Secdispatch] DANE IOT proposed outcome Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Eliot Lear
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Toerless Eckert
- Re: [Secdispatch] DANE IOT proposed outcome Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] DANE IOT proposed outcome Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] DANE IOT proposed outcome Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Ash Wilson
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] DANE IOT proposed outcome Michael Richardson
- [Secdispatch] Confusing terminology was Re: [Iot-… Mohit Sethi M
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Mohit Sethi M
- Re: [Secdispatch] Confusing terminology was Re: [… Eliot Lear
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Mohit Sethi M
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Ash Wilson
- Re: [Secdispatch] DANE IOT proposed outcome Michael Richardson