[Iotops] draft-hsothers-iotsens-ps-03 (was: RE: Request for slides for IOTOPS)

[Esko Dijk <[e-mail]>]

Hi Dirk,

Thanks for drawing our attention to the draft!

In the ANIMA WG we are working on Constrained BRSKI (https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher) which aims to deliver BRSKI bootstrapping while meeting constrained / IoT device and network requirements, such as those highlighted in your draft and in RFC 8576.  This can work without any user interaction and doesn't require an additional OOB channel, nor a secure channel. Standard operation uses X.509 certs (roughly 0.5 KB each) but for more constrained cases it can also work with raw public key (RPK) for operational device identity.

So it does provide secure authentication of an IoT device and also further things like "rebootstrap" into a new domain or renewal of identity within a domain. Some potential gaps I still do see i.e. what Constrained BRSKI is not providing:

1. A standardized way to (securely) tell an IoT device "do factory-reset" i.e. "forget your operational identity (LDevID) and go back to bootstrap mode". 

2. Configuring a new device at application level - e.g. if a broken light bulb is replaced, the new bulb automatically is configured in a replacement role, taking over all the configuration/responsibilities that the old bulb had.  This aspect is also mentioned in your draft in 5.2. Still to be determined is what part of this can be defined in IETF, and what part is up to the application ecosystem (e.g. Matter, OCF, KNX, etc.)

3. Bootstrapping without network infrastructure available (notably the "Registrar" and "MASA" hosts are required for BRSKI). For this BRSKI-PRM is being defined (https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-05) but it doesn't have a constrained equivalent yet. 

4. Make use of environmental / sensed signals to help in secure authentication of IoT devices: BRSKI doesn't depend on this currently. Could these signals help in some way? Your draft hints at doing this but it could use some more details perhaps on how to do this. As an example: only autoconfigure a light bulb as "living room light" if it's radio can sense other living room devices and vice versa. If that's not the case, a human user can still manually configure it - overriding any autosuggested configuration for the new device. A bunch of use cases like this could clarify what you would like to do with such environmental signals.

5. How the operational identity / key is used to gain access to the secured IoT network (e.g. wireless or wired, 6LoWPAN, ... ). This is currently left to the specific technology to be defined. Some (6TiSCH) are defined in IETF scope while others may be defined outside IETF.

Regards
Esko

-----Original Message-----
From: Iotops <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, November 8, 2022 16:17
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Iotops] Request for slides for IOTOPS

Dear all,
thanks to the lively discussion during the session today covering topics of onboarding, securing and controlling access, and authenticating IoT devices there was no time left for AOB where we would have pointed to our recently updated draft on "Need for New Authentication Methods for Internet of Things" discussing the problem statement and potential IETF work for technology agnostic authentication of 'dumb' devices:
https://www.ietf.org/archive/id/draft-hsothers-iotsens-ps-03.txt 

Thanks for reading and reviewing - next time we will apply for a slot in time!
Best regards
Behcet and Dirk

-----Original Message-----
From: Iotops <[e-mail]> On Behalf Of Alexey Melnikov
Sent: Montag, 7. November 2022 15:42
To: [e-mail]
Cc: [e-mail]
Subject: [Iotops] Request for slides for IOTOPS

Dear presenters,

Please send your slides for the IOTOPS @ IETF 115 session by the end of Monday, November 7th.

Thank you,
Alexey
-- 
Iotops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iotops

-- 
Iotops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iotops