- iot-wg - mailman.ripe.net

CIRA Labs - Secure Home Gateway (SHG) Project Update
by Jacques Latour 27 Mar '19

27 Mar '19

Hi All, Someone told me I'm not communicative enough ;-) Just wanted to give a quick update on the Secure 'IoT' Home Gateway initiative, we made good progress over the course of the last year, you can find project information here. https://github.com/CIRALabs/Secure-IoT-Home-Gateway · https://www.circleid.com/posts/20190305_an_update_from_cira_on_iot_security/ We're starting the 3rd phase of the project April 1st, looking at having fully running code, API definition and internet drafts for the gateway provisioning process, MUD controller and supervisor, IoT onboarding, SIDN SPIN integration, SHG APP and more. All this on top of the Turris Omnia platform. Still have along way to go. We can use some help. For those interested, the Government of Canada and ISOC started a multi-stakeholder process focused on IoT security and made recommendations on network resiliency, on labelling and on consumer education and awareness. There's good stuff we generated: https://iotsecurity2018.ca/ Added a picture to attract your attention :) [cid:image003.png@01D4E496.B21E1410] That's my report :) Someone from the team may be available to present at RIPE 78 Reykjavík in 54 Days 03 Hours 46 Minutes 49 Seconds. Jacques Jacques Latour - CTO & CSO Canadian Internet Registration Authority (CIRA) Tel: (613) 237-5335 [ext.294] | www.cira.ca<https://cira.us17.list-manage.com/track/click?u=02a9cbf99c1f9e5635e527e59&i…> [https://gallery.mailchimp.com/02a9cbf99c1f9e5635e527e59/images/0da6ac5e-6e5…]

1 0

Candidature for Co-Chair
by sandoche Balakrichenan 27 Mar '19

27 Mar '19

Dear all, I would like to put my application for the co-chair role. I believe I could fit into Jim's criteria, not being among the usual suspects :-) _*About my *_ I have been working at the French domain registry (Afnic) for the last 10 years. Since the beginning, I have been carrying out multiple IoT-related initiatives and projects internally and/or with partners. My linked in profile: https://www.linkedin.com/in/sandoche-balakrichenan-2a44645/ 50% of my job profile is oriented towards technology watch, and thus involved in activities at the IETF, GS1 (RFID, Barcode standardization), AIOTI (The Alliance for the Internet of Things Innovation), RIPE, CENTR (Council for European Top Level Domains) and LoRa-Alliance. My interest in IoT includes identification, name resolution, service discovery and using DNS infrastructure as PKI for the _*Some milestones in my IoT profile:*_ * I had participated for two years at the European Commission as an invited member of the IoT expert group. * Our IoT project WINGS (how DNS could be used for service discovery in the supply chain industry?) was awarded the CENTR R&D award for 2013 (https://www.inria.fr/en/centre/lille/news/anr-verso-wings-project-wins-cent…) * Principal contributor to the ONS standard (https://www.gs1.org/sites/default/files/docs/epc/ons_2_0_1-standard-2013013…) * Contributed to LoRa-alliance (lora-alliance.org) Backend interfaces specification on DNS usage for resolving LoRa devices in the Internet. _*What I could do in the Co-chair role?*_ * Will be able to participate in all RIPE physical sessions and other side meetings which a WG co-chair is supposed to attend. * Wil be able to allocate time to follow the policy proposal relevant to the WG; follow and respond to the mailing list discussion; ensure milestones and with the help of Jim, liaise with RIPE NCC. * Will be able to allocate time for administrative activities (like soliciting contents, preparing the agenda etc.) concerning the WG If you believe i can be of use, thanks for your support. Regards, Sandoche BALAKRICHENAN

3 2

appointing another co-chair
by Jim Reid 26 Feb '19

26 Feb '19

Here's what I posted back in November: 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. I would also ask candidates to start a *new thread* -- eg "Your name for co-chair" or something like that -- when they post on the list so there are meaningful and relevant Subject: headers which make it easier to make a consensus judgement. This will also make it clearer for other members of the list to express their support for a candidate.

1 0

re-rebooting the co-chair appointment process
by Jim Reid 26 Feb '19

26 Feb '19

Colleagues, we're still missing a co-chair. The last attempt to find one didn't work out. Although a couple of names were mentioned, there were very few voices of support for any of them - certainly not enough to make a sound consensus decision. It's time for one more heave. I suggest a call for nominations/volunteers/stuckees which ends on April 5th. That gives us 6 weeks for potential co-chairs to be identified and hopefully someone to emerge as the new co-chair. If the results by then are still inconclusive, I'll talk to Hans-Petter about how best to invoke article 5 of our appointment process. Let's hope it doesn't come to that. Please limit your comments on this thread to the proposed time-line and how to solve the problem of lack of WG consensus if this happens this time. I'll post another article for would be co-chairs.

1 0

Proposed Updates to EU RED Directive to increase IoT security
by Marco Hogewoning 14 Feb '19

14 Feb '19

Dear Colleagues, As I mentioned in my presentation to the Working Group during RIPE 77, the European Commission is thinking about updating the Radio Equipment Directive with the aim of improving IoT security. As a quick refresher, the RED applies to all equipment that has a radio on board. The legislation has a few broadly-defined terms regarding security and safety, which can be filled in on a later date. Last year, a number of member states floated the idea of using this option to increase security for a number of IoT devices, mostly toys and 'smart wearables’, for e.g. smart watches and step-counters. The European Commission has now opened a four week ‘feedback’ period on what is called an ‘Inception Impact Assessment’. This means the process is at an early stage and not very specific, and they are seeking feedback from stakeholders on their thoughts so far. As expected, the proposal currently does indeed target toys and wearables. Of course, this could change or be expanded later. Here are the key questions in the Inception document: - The overall objective of this initiative is to ensure an adequate level of security for internet-connected radio equipment and wearable radio equipment at the moment of placing on the market. - The following policy options and their effects for potentially affected parties (e.g. manufacturers, consumers, National Authorities) will be analysed: - Option 0, baseline scenario: a situation in which manufacturers are not obliged to implement any specific measures as it is currently the case. - Option 1, a situation whereby the industry self-regulates to implement the existing legislation which protects personal data, the confidentiality of telecommunications, security and protection against fraud. - Option 2, adoption of a delegated act pursuant Article 3(3)(e). This will require that radio equipment incorporate safeguards to ensure that the personal data and privacy of the user and of the subscriber are protected, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 3, adoption of a delegated act pursuant Article 3(3)(f). This will require that radio equipment incorporates certain features ensuring protection from fraud, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 4, adoption of a delegated act pursuant both Articles 3(3)(e) and (f). In this case, both requirements in Options 2 and 3 will have to be demonstrated for the purposes of market access. More information about the process and the Inception Impact Assessment is available from https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-64269… The deadline to submit feedback is Monday, 4 March 2019. This is the very early stage of the development. If a more formal proposal is drafted based on one of these policy options, there will be another 12-week consultation period. At the same time, please be aware that this process could result in a so-called ‘Delegated Act’, which does not require the formal approval of the European Parliament or Council and can come into effect very quickly. Regards, Marco Hogewoning Senior External Relations Officer RIPE NCC ------------------ Summary ------------------ RED security Inception Impact Assessment Feedback period: 4 weeks ending on 4 March 2019 Possibly followed by a 12 week consultation period

3 3

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

Re: [iot-wg] Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Jayden Rowley 17 Dec '18

17 Dec '18

Thanks for all the help and explanation regarding - https://1921681254.xyz/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Töma Gavrichenkov 06 Dec '18

06 Dec '18

Hello dear WG, Did anyone miss IoT DDoS attacks? They are back. And, this time it's not those nice Smart Home appliances everybody's so keen to talk about. It's industrial IoT nowadays. "...with this simple picture in mind, an attacker already knows which product is worth targeting in terms of exposed hosts. For example, by inspecting Kepware messages, an attacker can learn that this product is popular for the management of solar panel plants". https://documents.trendmicro.com/assets/white_papers/wp-the-fragility-of-in… | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

2 2