IOTOPS @ IETF 120

Thursday, July 25th, 2024
15:00 (Vancouver, UTC-7) / 22:00 (UTC)
1.5 hours

Meetecho: https://meetings.conf.meetecho.com/ietf120/?session=33026
Notes: https://notes.ietf.org/notes-ietf-120-iotops

Chairs: Alexey Melnikov and Henk Birkholz

Note Taker: Sean Authelet, Nicholas Freeman

Agenda

15:00 Administrivia
(5 min; chairs)

15:05 A summary of security-enabling technologies for IoT devices.
https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-summary-02

(10+5 mins; Brendan Moran)

15:20 Terminology for Constrained-Node Networks
https://datatracker.ietf.org/doc/html/draft-ietf-iotops-7228bis-00
(10+10 mins; Carsten Bormann)

15:40 Comparison of CoAP Security Protocols
https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-06

(10+5 mins; Francesca Palombini/John Mattsson)

16:30 END

Administrivia

Warren Kumari, AD:
Greetings, IETF NomCom cycle is beginning again, area director positions
are opening, if anyone is interested to learn more about the
position/job I'm open to chat. Either reach out or submit your name when
the nominations open.

Henk Birkholz, Chair:
Note Well remarks and reminder of recorded session. Reminder to treat
contributors with dignity, respect, and courtesy. Reminder to utilize
the 'raise hand' tool to keep the comments and questions orderly.

Carsten Bormann requests additional 10 min for presentation. Granted.

Brendan Morgan Presents: A summary of security-enabling technologies for IoT devices

Summary: Current draft documentation is intended to address mapping
requirements, solutions, and available implementations. Discussion on
current status of requirements douments, and requesting additional
reviews and input on current working draft before conditions are met for
WG last call.

Brendan:
Discussing the motivation of the current draft and current standing.

How do you find what libraries to use to satisfy implementations
security requirements?

This draft will help someone know which standards to use to solve a
security requirement according to ENISA guidance.

Baseline IoT security requirements for Critical Information
Infrastructures.

Guidance to the implementor, for example -
Use SUIT to deploy your security updates.
Recommending using the TEEP protocol for negotiating TEE.

Current status of security requirements documents:
ENISA's Baseline Security Recommendations for IoT in the context of
Critical Information Infrastructures
ETSI's Cyber Security for Consumer Internet of Things: Baseline
Requirements
NIST's IoT Device Cybersecurity Capability Core Baseline

The draft maps requirements to the standards that address them but not
mapping to libraries that implement the solution. The draft does not
present procedural standards describing the handling of implementation
processes (E.g. key handling procedures)

Status of draft, unchanged since IETF 119. Requesting additional
reviewers. Acknowledge a recent reviewer that needs to be addressed.

Draft may need more justification and/or explanation around 'procedural'
and 'architectural' requirements.

AJ:
Will provide assistance on the draft. Willing to be a co-author.

Brendan Response:
Current draft does not have a pointer back to the current Git repo but
planning to reconcile and share.

Alexey Melnikov, Chair:
Are we already ready for WG last call?

Brendan:
Not ready for LC until AJ's concerns addressed.

Alexey Melnikov, Chair:
Brendan, do a draft revision to address AJ's comments and we can see
how many changes are made after review is addresses. Then we'll decide
if conditions are set for 'last call'.

Henk Birkholz, Chair:
August revisit for WGLC.

Carsten Bormann Presents: Terminology for Constrained-Node Networks

Summary: Recommendations for updates to classification framework for IoT
devices and a more frequent review of RFC to prevent documentation from
falling out of relevance in a rapidly changing industry.

Carsten Bormann:
This RFC has been somewhat stuck the last few months. Addressing the
needs for updates. Poses questions: Has the world moved on? Is there
terminology missing?
RFC 7228 is 10 years old, bares 42 references by other RFCs,
terminology has changed, necessitating updates.
Power constrainedness is an example of a term we need to add.

Brendan:
Point out that IoT is a rapidly changing landscape, microcontroller
capability for requisite cost is significantly lower than the current
classification levels in the documentation.

Carsten Bormann:
Distinguishing classes still makes sense for the current environment.
Class boundaries should be descriptive of requisite device capability.
Use the class delineation to support speech that assists in discussions
about functionality that would be desired in protocols.

Carsten Bormann:
Proposal of new classes descriptive of levels of software update
capbilities of the device.
e.g.:
Firmware/software upgradability
Isolation functionality
Secret shielding functionality

Brenan:
(on slide 12) Point out discrepancy in verbaige of 'execution
environment' and 'secure enclave'

Henk Birkholz, Chair:
Published in chat a diagram to help discuss confidentiality classes

Carsten Bormann:
Classify devices based on keeping time over Power Events (slide 14)
Recommended plan for refining classification verbiage by:
Focused discussions on the mailing list.
Review pre-WGLC
Goal: final update and WGLC by the end of the year.

AJ:
Agrees with plan. Has anyone of industry (fabrication experts) reviewed
this plan for updating classification?

Carsten Bormann:
We have asked them for review of this plan.

AJ:
Will share with contacts in NIST Hardware Security Area to solicit
feedback.

Carsten Bormann:
We need to keep this document useful for people as a reference
especially for the industry SME's.

AJ:
How do we make the document more flexible for industry use and review?

Carsten Bormann:
It would be good to have a new RFC. We also might want to update it
more often to save the effort of waiting too long to update based on the
rapidly changing environment. Recommend building in mechanism to
determine update timeline.

Henk Birkholz, Chair:
Solicits summary of new categories distributed to the mailing list to
stoke interest and review.

Carsten Bormann:
Acknowledged.

John Mattsson Presents: Comparison of CoAP Security Protocols

John Preub Mattsson:
Changes between 04 and 06-
04 addressed the early IoTDir review by Russ Housley.
05/06 reflected editorial chanfes only.
WGLC on 06. Reviewed by Marco Tiloca and Thomas Fossati.
Next steps: address comments on RFC 9528 and 9529
Possibly add considerations for TLS extension, publish at time of cTLS
release.

Alexey Melnikov, Chair:
Revise and possibly wait for cTlS before proceeding with publication?

John Preub Mattsson:
Yes.

Open Mic

Michael Richardson:
Comments on charter. Regrets not doing more protocol related things in
this WG. Configuration backup and restore of end devices may be a topic
worth considering as a part of the WG. Conerns about an implementation
awaiting an RFC but an RFC will not be published until a demand signal
from implementations. Calls to WG to make suggestions for
standardization.

Warran Kumari:
Revisiting the charter may be helpful.

Henk Birkholz, Chair:
To the comment on restore and management, the SUIT Manifest was
deliberately not designed as a protocol. Protocols for management,
replay, and restructuring would be interesting.

Brendan:
We can consider a protocol that lives on top of SUIT. We have not yet
described them working together yet. Unsure if this is a SUIT WG topic
or IoT WG topic. Open for discussion.

Josh Cohen:
Revisiting proxy discover since last update. Asking the room for
feedback: When and if proxys are used in IoT devices?

Brendan:
Proxys have largely been displaced by CDNs.

Michael Richardson:
No. People do not know how to do this. The proxy would serve as more of
an obstacle. Today's consumer IoT devices do not in general have that
setting.

Josh Cohen:
Proxys may exist in the network the users don't handle but that does
not mean they do not exist.

Michael Richardson:
If there are proxies in the network, they are ignorant of them. They
expect them to reach the web via default route. If they can't, devices
will be returned to the seller as "broken".

Henk Birkholz, Chair:
OSCORE achieves the same effect as a proxy.

Josh Cohen:
Currently there are situations where an IoT device cannot get to the
internet because of an obstacle?

Michael Richardson:
There are networks that they work and those that don't. There might be
gateways that offer support for industrial IoT but normal consumers are
deploying air gaps. If you have a proxy discover mechanism I don't think
it will be interesting to those vendors.

Carsten Bormann:
MQTT is a possible solution to explore.

Henk Birkholz, Chair:
If we formalize a problem statement for today's requirement for proxy
usage that is not solved by OSCORE we can move out from there if there
is real world interest. But formal problem statement is required.

Meeting adjourned by chair at 1558.