# T2TRG IETF 102 Summary meeting Thursday, July 19th, 2018, 15:50..17:50 EDT (UTC-04:00) Note takers: Christer Holmberg, Eve Schooler, chairs Github agenda: https://github.com/t2trg/2018-ietf102/ ## Intro, RG Status (Chairs) Carsten presented the Next Steps in Security topics that will be presented later (slide #5). Presenting the scope and goal of the T2TRG (slide #6). Eve S: should be just focusing on constrained nodes? Edge computing, and other cases with not only constrained nodes. Carsten: Slide coming on the topic. Important one. Presenting recent activities (slide #7). WISHI (Work on IoT/Semantic Hypermedia Interoperability) - bi/tri weekly calls and hackathons. Joint work with other SDOs: W3C, OCF (CoAP and CBOR related), OMA SpecsWorks. Regular meetings with OCF on CoRE - partially research, partially engineering. Mohit: when security draft going forward? Carsten: slight coordination still ongoing with IESG. Will be pressing publish button very soon. Identified research topics (slide #8) 1. We already have good ways to describe data models, now let's consider good models that enable extracting info from byte strings and upgrading to data model level of JSON/CBOR 2. Generate a working example of semantics in action (e.g., a light) 3. Protocol evolution Robin Wilson: Correct; lights may seem simple, but aren't. Personally use as example for privacy implications. Metamodel: on/off. Gap between UI exposed data and data that is used. Privacy gap there. Could be security considerations for research. Peter vdS: How formal we want the models to be? UML, VDL? Carsten: no idea at this moment. want to learn. If formal model helps, we should. Let's see. Peter vdS: what is the added value needs to be considered Next meetings (slide #9). WISHI calls will continue. Meetings with OCF (virtual and/or F2F). Virtual meetings with OMA SpecWorks planned. Bangkok#103: IoT Edge Computing session and in-network computing? WISHI hackathon? Co-locating with academic conferences 2019? Community is asked to suggested suitable events. Edge and In-Network Computing (slide #10): Harkens back to Active networks (wasn't particular successful - should try to avoid those pitfalls this time around). Multiple RGs working with associated activities: T2TRG, ICNRG, DINRG, PEARG. Joint meeting at IETF#103? Other activities: e.g., presentation at IETF 100 on edge computing, recent submission: draft-hong-iot-edge-computing. RG doc status (slide #11): State of the art and challenges for the IoT security: READY. RESTful Design for IoT: Hypermedia guidance included in -01. More IoT specifics througout the draft: REST constrainst in IoT, IoT related system characteristics. Since often cannot update all devices simultaneously, need to accommodate protocol evolution. Next step: author review, then submit new version for broader review. Not a RG document (slide #14): Survey: draft-sarikaya-t2trg-sbootstrapping. Carsten: Do we have the energy/interest to work on this? Interested parties are requested to talk to the chairs. Kerry: commonality between this and the secure updates work? Carsten: secure updates already in the SUIT WG. If interest moving forward, provide reviews and perhaps even more material. ## Report from WISHI and Hackathon (Michael Koster, chairs) Bi-weekly tel-meetings between IETF meetings. Participation in IETF hackathons. E.g., Topics include W3C WoT Thing Descriptions, processing models, terminology for layers, integration of IoT with Energy, impact of JSON LD 1.1 work on Thing descriptions, W3C plugfest and WISHI, iot.schema.org, etc. Work with other SDOs, including automotive group GENIVI VSS. Good Thing description (slide 22). Information and Data Models. Enables describing both "What I want to do" and "How I want to do it". WISHI hachathon objectives: Test applications from different vendors/contributors. Work focusing on mapping. Example results: demo'd interop between generic clients and diverse devices, RD implementation up to speed and ready to integrate with TD. Peter vdS: discovery use cases and scenarios with security aspects? Koster: lot of security aspects, including semantics. Who is allowed to discover what, etc. Part of the workspace here. Realized that we have a good and complete tool set - focus on using it. Setup is still a big issue: took most of the 1st day of the hackathon ## iot.schema.org update (Michael Koster) Used in WoT plugfests and WISHI hackathons. Validated basic schema. ## W3C update (Matthias Kovatsch) What? Counter fragmentation in the IoT. Building block: TD (Thing Description): data, events, and actions. JSON based representation format. Building block: WoT Binding Templates: mapping of interaction model to concerte protocol operations (e.g., COAP). Building block: WoT Scripting API: standardized JavaScript object API. Mature work: started in 2014. Now almost in the end of original charter. Added few months to the end of charter to acommodate for JSON-LD 1.1. Simplified TD - JSON-LD 1.1 processing - Semantic annotations optional - JSON schema compatiblity - New terms A few things still to do before the release. IANA impacts: application/td+json and CoAP Content-Format number. Align links field with draft-ietf-core-links-json. Security and Privacy: Is needed, but much work will be outside the scope of the upcoming relase. Work will continue. Ari: if interested in semantics / hypermedia interop work, please join the WISHI calls and hackathons. More information in the wiki and in announcements sent to the mailing list. ## Next steps in security ### Automated IoT Security (Oscar Garcia-Morchon) Draft: draft-garciamorchon-t2trg-automated-iot-security Goal: solve mismatch between security capabilities and settings with which IoT devices are designed/manufactured/deployed. Goal: Security reqs of IoT devices. Problems: different environments, evolving threats, wrong pre-configuration. PASC: Protocol for Automatic Security Configuration: provide security that fits the specific deployment environment. PAVA: Protocol for Automatic Vulnerability Assessment: automatic configuration (PASC) based on continous vulnerability assessment. Benefits for manufactures, sys ops and end users ("don't need to do anything"). Carsten: Looks interesting. Fits very well with the currently ongoing work. Hannes T: How does the sec conf look like? Oscar: Could be based on different methods (e.g., access control rules). If have ideas or comments, send e-mail. ### Enabling Network Access for IoT devices (Mohit Sethi) Why do IoT devs need access? Services in the cloud, software updates. Problems: discovery and configuration (which network, which cloud server,...), security bootstrapping. Problem solved for laptops. How to do the same for IoT devices? Challenges: limited UI, scalability, mere mortals setting up the network (vs admins), range of wireless technologies. Current methods for network access auth: manual, managed. Interest in the RG to document these? Hannes: Makes sense. Commit to review. Has own ideas. Carsten: eduroam does this; we know the basic system works. In eduroam have all the contracts for building federation. What is the legal framework that would make something like this work? Bad actor could have EAP server that accepts connections from who pays me. Hannes: universal problems. Mohit: how to redirect authentication queries from one service to another. Fine if diverting to competing service. Carsten: can be surprising threat models. Börje: small manufacturer goes out of business; what happens with the device? Mohit: this method actually helps in that case. Can direct your queries to other place than just vendor. Open source community could take this. OpenWRT devices can be flashed with own firwmare for example. Can peer with other services too. ### Next Seps in Security? (Rene Struik) Focusing on crypto aspects. Secure key material and storage - minimizing overall implementation cost. Can we use only single public key pair for key agreement and signing? Saves cost that could be used in other parts to improve security. Can use single symmetric key? Do we need high-quality random seeds? Hannes: did seminar on RNG topic. Went to see how common RNGs are in microcontroller. Turned out that ST micro alone have +400 low-end microcontrollers with RNG there. But you can also pick option that doesn't have. Haven't checked other vendors yet. Good to remember that not all microcontrollers are Internet-connected. Well recognized that we need randomness in keys - could be that the implementation of AES needs randomness as well. Not all things have home in IETF. But good to point out. In post-quantum world may need to send much longer packets due to longer key and tag needs. Can be problem for constrained devices/networks. Kristy Paine: AES256 pretty standard. With pub key crypto, discussion ongoing to design new versions to be post-quantum resistent. Don't need to use large parameters. Crypto agility is important; if something learned to be weak, needs to be able to update. Robin Wilson: how PKI ought to work (?). Spoke with PKI vendor; he said this is going to be year of PKI. Said same two years ealier. 2009 shipped billion PK-pairs. Not worth extra 15 cents to embed keys in certificates. Learning: should always re-visit assumptions. Mass-deployment of PKI was in fairly dumb devices, cable modems, set-top-boxes, smart meters. Don't bother having management interface to change keys, would change device. Good to validate assumptions. For these device cost-to-difficulty ratio? If solution to problem is to replace a device, you may not care of all these problems. How does one limit the impact of key compromise? Short-lived certificates at reduced cost? could "ledger" as key repository help? Other questions: What about key provisioning, device config and commissioning? What about privacy and control? Bluetooth toothbrush that requires Internet connection to work is an existing horror scenario. ### Decentralized Trust for IoT and In-network-computing (Dirk Kutscher) "There is no JSON code in this presentation" :-) Context: Industrial IoT, Multiple realms (a hierarchical depiction of the network/devices and their control). Factory/Enterprise network as a multi-tenant environment. China Mobile example: Beyond Edge computing. Data Logistics - IoT data flows upstream and fusioning, which presents latency, trust and scale issues. Therefore cloud-based model not always optimal. Consider In-network computing with client-server protocols. Implications of technologies such as Named-data networking (aka Information-centric networking). Vision: Compute-first networking, i.e., leverage increasing availability of computation at different scales. Move away from the overlay approach and integrating functionality instead into the network data plane. Named Function as a Service (NFaas). Treat unikernels as Named Data objects. Trust management quite important in this environment, particularly since they are compositional systems. Need to automate verification and enforcement. DINRG to discuss what are the requirements for Decentralized Trust Management. Carsten: Rene's work in LWIG and Dirk's work in ICNRG and DINRG tomorrow. Interesting set. In the WISHI phone calls we will discuss semantics for security (Which we didn't have time for today).