January 2019 - iot-wg - mailman.ripe.net

InnoITeam - a new Center of Excellence in IoT Science and Technology
by Artūras Serackis 01 Jul '19

01 Jul '19

Dear Colleagues, We are excited to introduce you a new initiative a Center of Excellence in IoT Science and Technology (InnoITeam). The CoE will leverage the knowledge, experience, and resources of three Lithuanian institutions – Kaunas University of Technology, Vilnius Gediminas Technical University and State Enterprise Centre of Registers of Lithuania - with the support of two advanced EU partners from Sweden – Linköping University and Interactive Institute Swedish ICT in Norrköping. During the first five years, the Consortium will focus on four R&D topics: 1. User interfacing and interaction design approaches for Smart Environments based on IoT. 2. Cybersecurity aspects of the Smart Environments based on IoT. 3. Data analysis and visualization approaches for data-intensive IoT environments. 4. Cognitive IoT technologies for Smart Home Environments. The InnoITeam project is funded by the European Union’s Horizon 2020 research and innovation programme and coordinated by the Kaunas University of Technology. The project has been already started in September (2017) and is finishing its first phase. During the second phase in a five-year period, the InnoITeam is planning to become a self-sustaining organization, integrating and supporting research excellence and innovation development in Lithuania, the Baltic Sea region, and Europe. Meet our team and recent news on our web page: https://www.innoiteam.com Follow us on social media: https://facebook.com/innoiteam https://www.linkedin.com/company/innoiteam/ https://twitter.com/innoiteam

8 9

appointing a co-chair
by Jim Reid 08 Apr '19

08 Apr '19

Ladies and gentlemen, boys and girls, start your engines! :-) Since the WG now has an appointment process in place, it's time to use it. Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. Over to you...

5 5

algorithm agility for IoT
by Jim Reid 24 Jan '19

24 Jan '19

I’m working on a document at ITU Study Group 20 on algorithm agility. [So you don’t have to! :-)] The aim is to produce a Recommendation which essentially says “don’t hard-wire crypto algorithms into IoT stuff because what’s secure today could be insecure tomorrow”. For instance, building or deploying an IoT solution that can’t use anything but MD5 or DES (say) would be bad. Similarly, it would be undesirable to install a sensor network today that can’t handle tomorrow's devices because they might well use new crypto which isn’t around today. At the moment, the document cites the mechanisms used in TLS and DNSSEC as frameworks that those deploying and designing IoT infrastructure should consider. ie Continuously updated registries which add new algorithms when these become available and drop old ones which are considered unsafe or whatever. Please note that the document isn’t going to say everyone *must* use TLS and/or DNSSEC since that clearly depends on specific (unique?) use cases and requirements. Instead the document will say that people should take account of those sorts of frameworks when they are designing, procuring or operating IoT infrastructure. SG20 has said the document needs more examples of these kinds of frameworks. So I’m asking the list if they can suggest some. I’d particularly like to about potential examples from those developing IoT firmware or operating systems. Or authentication schemes for IoT. What sort of mechanisms and frameworks are available? What’s done in RIOT or the stripped down BSD/Linux stuff that underpins some IoT platforms? Anything else? The obvious example that springs to mind are dynamic SSL libraries - for instance the package managers that supply the latest version(s) of OpenSSL. Or the replacements for that which sprung up after the Heartbleed incident. However that’s a bit fuzzy. I suppose CAB Forum advice on X.509 certificates might be another. But there must be more. Any suggestions or pointers?

5 5

Re: [iot-wg] algorithm agility for IoT
by Jim Reid 21 Jan '19

21 Jan '19

> On 21 Jan 2019, at 12:36, Andrei Kolesnikov <andrei(a)rol.ru> wrote: > > Consider this problem of "hard wired crypto" only for specific class of IoT devices: power hungry, long-live, manageable, internet connected. The similarity must be with any user premises equipment, such as wifi routers, cameras, etc. I’m not sure that’s true Andrei. If an IoT device is on the Internet, it shouldn’t have hard-wired crypto. Just like how it shouldn’t have a factory-set password of 0000 or whatever. This should not be a subject for debate. It’s basic common sense.* Whether that device is a node in a sensor network or some piece of CPE is irrelevant from that perspective. Of course there are lots of trade-offs to be made when selecting crypto solutions for IoT: device lifetime, power, key lengths & rotation capabilities, memory & CPU capacity, bandwidth, costs, etc, prevailing policy & legislation, etc. But that’s an entirely different discussion which is orthogonal to the matter at hand. * It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...

3 4

Fwd: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues
by Töma Gavrichenkov 11 Jan '19

11 Jan '19

Hello WG, Here's a today's announcement from the NANOG mailing list. Some of the RIPE IoT working group members may want to take a look. -- Töma ---------- Forwarded message --------- From: Rich Kulawiec <rsk(a)gsp.org> Date: 10 Jan. 2019 г., 19:23 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues To: <nanog(a)nanog.org> The "dumpsterfire" mailing list is for the discussion of security and privacy issues related to the IoT (Internet of Things). Arguably, the entire IoT *is* a security and privacy issue, but we'll get to that in good time. If you want to join, you can either use the list's web page: http://www.firemountain.net/mailman/listinfo/dumpsterfire or the list's subscription/unsubscription address: dumpsterfire-request(a)firemountain.net The list is public and so is its archive. ---rsk

1 0