Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

["Panwei (William)" <[e-mail]>]

Hi Toerless,

You're right, there're many ways to identify the device. But In the DANE client authentication case, the device's identity can only be the certificate or a public key pair, I think, because the DNS Server needs to store the public key hash values.
Except the initial identity, the device may be allocated a local identity after onboarding. So if the device has an initial identity of symmetric key, it has to be allocated a local identity of certificate or public key pair, then the local identity can be bound to a DNS domain name.

Regards & Thanks!
Wei Pan

-----Original Message-----
From: Secdispatch [mailto:[e-mail]] On Behalf Of Toerless Eckert
Sent: Monday, November 16, 2020 10:47 PM
To: Eliot Lear <lear=[e-mail]>
Cc: [e-mail]; [e-mail]; Panwei (William) <[e-mail]>
Subject: Re: [Secdispatch] [Iot-onboarding] DANE IOT proposed outcome


Wrt. beyond thin device requiring at least a public key pair:

I thought there where also mechanisms by which the thin (IOT) device might only have a unique symmetric key that is only shared with some less constrained proxy ("in the cloud") that is supporting the thin device in all more complex (crypto)  operations and avoid the need for the thin device to support symmetric crypto - if thats the component beyond its capabilities. 

Aka: Many ways to cut the cake. 

On Mon, Nov 16, 2020 at 01:50:30PM +0100, 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) <[e-mail]> 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:[e-mail] 
> > <mailto:[e-mail]>] On Behalf Of Eliot Lear
> > Sent: Monday, November 16, 2020 6:55 PM
> > To: [e-mail] <mailto:[e-mail]>
> > Subject: [Secdispatch] DANE IOT proposed outcome
> > 
> > Thanks to Shumon for presenting the DANE use case for IOT.
> > 
> > We discussed taking this to the [e-mail] <mailto:[e-mail]> 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
> > [e-mail] <mailto:[e-mail]> 
> > https://www.ietf.org/mailman/listinfo/iot-onboarding 
> > <https://www.ietf.org/mailman/listinfo/iot-onboarding>
> 



> --
> Iot-onboarding mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-onboarding


-- 
---
[e-mail]

_______________________________________________
Secdispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdispatch