Notes for Paris T2TRG Interim Meeting

Co-located with the "Hackathon on Lightweight IoT Security" in
Paris on May 21/22 2024.

Video: https://www.youtube.com/watch?v=u7CmNaFyhm4
Slides:
https://datatracker.ietf.org/meeting/interim-2024-t2trg-01/session/t2trg

Participants:

1. Abhishek Kumar
2. Ari Keränen
3. Carsten Bormann
4. Christian Amsüss
5. Eliot Lear
6. Elsa Lopez Perez
7. Emmanuel Baccelli
8. Fabian Graf
9. Francesca Palombini
10. Gabriel López
11. Geovane Fedrecheski
12. Göran Selander
13. John Preuß Mattsson
14. Joonas Björk
15. Kerry Lynn
16. Laurent Toutain
17. Mališa Vučinić
18. Manoj Gudi
19. Marco Tiloca
20. Michael Koster
21. Muhammad Usama Sardar
22. Rafael Marin-Lopez
23. Rajat Kandoi
24. Renzo Navas
25. Rikard Höglund
26. Sara Faour
27. Simon Bouget
28. Stefan Hristozov

CB doing introductions, showing chairs' slides.

(p7): T2TRG was created when first set of IoT application layer
applications were done. Expectation is that even though not all nodes
involved in the IoT will be resource constrained, low-resource devices
will need to be able to participate in communication.
(p8): Groups of talks here -- infrastructure (2 talks), post-quantum
(its implications for the IoT world), specific application areas (2
talks)

And we will discuss which breakouts we need tomorrow. See
https://parishackathon.lakewg.org/

Secure In-network Data Fabric for IoT applications

Rajat Kandoi presenting remotely on behalf of AK.

(p1): For IoT applications, more time is spent today in integration
related work than in creating insights from data.
(p4): looking more deeply into data fabric: brokering infrastructure.
Rather than binding data to a specific source URL, it is independent of
location. Data handlers do in-network / on-path processing, instantiated
by service broker.
(p5): using more than the listed standards, but those particularly
relevant in this context
(p6): simple proof-of-concept handlers -- filtering, aggregation;
normalization of the data format early in the pipeline to foster stream
processing over batch processing. Data handlers can be running on the
devices themselves with conditional notification.

Muhammad Usama Sardar: On security slide, mentioned plans on TEEs and
remote attestation. Already concrete plans?
RK: Not subject-matter expert. As far as I can tell, thinking of Azure
confidential computing and Intel SGX for example. On remote attestation,
we have RATS in IETF, but also working on own tools agnostic of
underlying infrastructure. Can follow up in e-mail on details.

Eliot Lear: How central is 6G to all of this? Is 6G the proper
abstraction layer to look at, how does this look at in local network or
BLE?
RK: 5/6G also looks into private networks and local deployments for
enterprises. 5/6G can also be backhaul for Wi-Fi frontends. On more
abstract view, it's just application running on underlying
infrastructure. If that infra provides capabilities needed by the data
fabric, it can run on that. However, especially cellular networks are
becoming more programmable and we will integrate with that
programmability, taking advantage of dynamic QoS and authentication
features. Running on 5/6G will provide an edge over generic
infrastructure because it has that. Of course 6G is still early vision.

EL: As you develop work, maybe define things at abstract level with
attributes needed at the different layers and let the layers sort out
what they provide, and you'll have something more generalizable.

Emmanuel Baccelli: You use eBPF. How does it fit in the picture?
RK: At investigating stage. Investigating if can e.g., filter or
duplicate data already at kernel layer.

How can AI be distributed in the computing continuum? Introducing the neural pub/sub paradigm

Abhishek Kumar presenting.

(p1): This is close to previous talk's goals: Making data available
where needed.
(p2): Expecting lots of data movement, associated with carbon cost.
Basic data type of metaverse is volumetric video, 5x data requirements.

(p4): Issue with pub/sub: Some entities may be low resource, may not
even do inference based on trained model, let alone train. Need
cooperative framework, infrastructure needs to support devices.
(p5): Roles in Neural Publish Subscribe. Ideally, co-locate Execution
Units with subscriber. Decompose into small units, units run
independently and in parallel, and where data is located to avoid
transporting it. Models move, data does not move. Thus, tackle
huge-bandwidth problem.
(p6): Patterns. Split model steps enhance privacy (M1 in one place,
later steps somewhere else).
(p7): Summary of the capabilities.
(p8): Ongoing demos.
(p9-10): two use cases on network data, NWDAF and ORAN
(p11): conclusion

Renzo Navas: On explainability. Worried about trend of black boxes. Can
this be taken into account?
AbK: Haven't focused on explainability. Focused on models that can be
split in small layers.
RN: maybe can add layers that help with explainability
AbK: able to split to smaller units and make explainable, but if want to
deploy advanced model that can't be decomposed, would be tricky

OS: How about discoverability?
AbK: neuro pub/sub broker knows what kind of models are scattered across
infra

Stefan Hristozov: Security aspects / problems considered?
AbK: Security is not direct focus of this project. Assuming that your
own personal network is secure. If embeddings can be reversed to raw
data, that'd be security problem; solvable by differential noise.
SH: Also aspects of model theft.
AbK: Yes.

Post-Quantum Cryptography: Overview and IoT Standardization Perspectives

Renzo Navas presenting.

(p1): Trying to do this short for discussion. State of things of PQ in
IETF, NIST etc.
(p3): Threat. Not sure if possible, better be prepared. (Asymmetric gain
vs. cost)
(p3/2): Capabilities of quantum computers.
(p3/3): With larger quantum computer, square-root time for symmetric
crypto -- 128 bit key is reduced to 64 bit strength.
(p4): Need mathematical problems believed to be unsolvable by quantum
computers. Some ideas from 70s already. Quantum crypto out of scope
here.
(p6): Status in NIST: standardized or soon going to be. Want solutions
based on both families in case broken. All but Falcon to be final this
summer.
(p7): KEM = 3-tuple of algorithms / operations, ek and dk ~= secret and
public key
(p8): not the same as Diffie-Hellman, but using terms. Behind that,
polynomials, transformations -- but focus on network here.
(p9): Only look at messages over the air: public key, ciphertext. (units
are bytes!). PK categories equivalent to breaking complexities.
(p11): 3 will be standardized; some more of the 40 remaining ones. More
classical: generate, sign, verify. Falcon is expensive to compute,
depends on floats.
(p13): See PQUIP WG aggregating from other WGs. Only informational.
(p13/2): All about hybridization: mix classical and PQ to have
guarantees of both. Transition to full-PQ if PQ stay strong.
(p14): How do we do KEM between constrained nodes? Need common encoding,
COSE abandoned but there is work ongoing again. No consensus in COSE
whether to do this or hybridization first.
(p15): Do we want quantum resilient IoT?

JPM: AES-128 is definition of Cat.1 -- NIST say that's good enough.
Multivariate is probably important for signatures with IoT. For some
IoT, firmware update is most urgent. Others may go for the same approach
as for DNSSEC, maybe wait-and-see.

EL: On p16, looks like great opportunity for a draft, this slide. Can
turn into nice discussion draft. In particular there'd be interest in
"when do we think we are going to meet God", what is risk over time,
when should we follow the big brother, what does it depend on (device
sunk into ground for 40 years), what is relation with timing attacks.
Big piece of work, great research topic. (Not sure if draft or even
submission to academic conference)
RN: Looking for collab, am not cryptographer.

Distribution of Software Updates with End-to-End Secure Group Communication for CoAP

Marco Tiloca presenting.

(p1): First time presenting this, was subject of design team meetings
with Göran and Christian.
(p2-3): Problem statement. Can we combine those components for use with
firmware updates, e.g., with SUIT?
(p4): Minimal firmware update.
(p5): Proxy deployed to improve performance, and to fetch firmware
update once in chunks and distribute it in smaller chunks.
(p6): Goals. Key provisioning done in group manager (e.g., using ACE).
(p7): Multicast notifications specified somewhere else, but found useful
here.
(p8): Proxy fetches relatively large inner chunks. Proxy caches data,
responds with error, client should stay ready for multicast transmission
at indicated time.
(p11): So far a bit of gambling whether server sends direct response or
schedules big retransmission.
(p12): Noticed possibility for incremental consistency checks. (Active
adversary could inject single crafted outer chunk).
(p13): Proxy can send short MAC based on group derived key material ...
but with material from where?
(p14): membership is easy but undesirable (gives it read access); could
have special role (comparable to signature verifier role).
(p15): More options of how to provide those outer chunk MACs.
(p17): Summary. Looking for co-authors.

CB: Looking forward to this draft. We have a long history in reliable
multicast ... (e.g., NORM and Flute).

Using onion routing with CoAP

Rikard Höglund presenting.

(p2): Tools we have. Enable clients and hidden services similar to Tor.
Forwarding instructions packed in layers of OSCORE.
(p3): No preconfigured OSCORE configurations.
(p4): Eligible existing proxies with their metadata.
(p5): Network overview in different cases.
(p6): Client picks 3 proxies to hide behind. Each proxy removes one
proxy layer and sees relevant forwarding instructions. Layers built from
bottom to top in figure.
(p7): Naming conventions. Built from public credential of service.
Discovering the address also gives the credential.
(p8): As client does, builds circuit; then, registers available hidden
service. Once circuits are set up, connected and E2E can be established.

(p9): Client side is forward proxies; server side needs new options to
set up reverse proxies.
(p10): Building "routing tables" on proxies, built up using those
options.
(p11): Outlook.

SH: Example use case where Tor-like capabilities are needed in IoT
setup?
RH: Same as with Tor, when like to hide identity of participants. Health
monitoring in small homes, possibly software updates.
SH: Don't know what Tor is used for.
CA: Important use case cargo tracking. Without something like this every
piece of cargo will reveal who it's being tracked for. With this it can
connect to network without revealing.
SH: So it's privacy preserving thing.

Wrap up

CB: How do we use the 9-11 tomorrow slot?
CB: One scheduled so far.
GS: People from Assa Abloy worked on EDHOC implementations and want to
look at how to make EDHOC more exposed, looking at interop servers. When
will that be?
CB: Other items before we schedule?
CA: Can give short report on today's M2M ACE topic.

AbK: 3GPP working on AI standards in 5G/6G context. Any efforts in IoT
community for that?
CB: Various coordinating activities, not aware of anything specific on
IoT. Would be good to enhance that collaboration, not sure suitable for
tomorrow.

CB: 2nd half (10:00-11:00) for Assa Abloy part. Meet a bit earlier
(09:40) for M2M discussion. In this room (A115), using Inria WebEx
because those are not formally part. Ask T2TRG chairs for link if you
did not get it.

[End of T2TRG Interim meeting.
The following are notes from hallway side meetings that followed;
included here for easy archival]

---

Side meetings / hallway discussions

Notes from some of the side meetings follow.
These are "hallway discussions" process-wise, i.e., not formally part of
the T2TRG meeting.
(So there also is no video.)

M2M authentication

CA summarizing

If device wants to delegate authority don't have good tools for that.
Now we name the parties: delegator, delegatee and relying party.

GS: when done, what do we have?
CA: delegatee should be able to do what delegator allowed without
needing it

Have a draft dynlink that delegator could use to tell another
constrained device to perform particular action when resource has
changed.
Who else around to talk to? Different scenarios if can reach AS. In all
scenarios need data item telling there is delegation associated with pub
key of delegatee. Delegator talks to AS and enrolls that client and
passes authorization. Can config delegatee to recognize AS. And then do
ACE like normally with AS using proof of possession key.

CB: credentials in step 1 mean identity? Know what DeeC is
CA: credentials as in EDHOC CRED-I
GS: we used word auth credentials to indicate pub key or cert
CA: pub key with some decoration

To relying party looks normal. Just receives token from AS. Can act with
existing SA.

In scenario where delegator sends data to delegatee needs to be signed
data item. Used like a token to access AS to perform regular ACE get
token procedure.

Third scenario has no AS at all. What appears possible, if delegator is
by AS authorized to recreate delegations and expressed in way relying
party can understand, can create own secondary AS with limited scope and
act like auth server towards delegatee and that can get a token, and act
almost like nothing had happened.

CB: step 1 could be piggybacked with 2?
CA: not sure, relying party might understand tokens
CB: anything DorC can do DeeC can do
....
CB: there may be scenarios where have hard time realizing #1 in basic
way described. Looking at ways piggybacking useful. Only traffic from
DorC to DeeC and relying party.
CA: could create data item that travels that way. Heavily influenced by
the power of attorney work

GS: workflow and params doc?
CA: once AS involved. Came up briefly. Largely orthogonal. To issue
token to client want to prove that client has pub key. Would be one leg
between XXX(?) and AS.
GS: thing you need to go with existing flows is req coming from client
to the AS. Delegatee client. What missing is secondary AS. What could
work, as long as req comes from ACE client to AS or 2nd AS, could use
the alternative flow to control access token on the relying party. 2nd
AS could be indicated by delegation. Can detail this in an email.
CA: changes something fundamental?
GS: no. Fewer nodes.
CA: saves from having to communicate between delegatee and AS?
GS: yes, if have secondary AS
CA: in that scenario alternative flow could be beneficial. Really great.
Would not need to set URI and RPK.

CA: "Power of attorney" team will refine. If have suggestions here, come
to the list.
SVS: how many scenarios will be there with delegatee and AS
communication. Yesterday discussed two.
CA: Split the AS unavail and AS avail further up. Workflows have
different properties. But same data items.

CB: generally want to look at all permutations. Should look if we have
credible usage scenario and then ignore, but we need to list them.

OS: will also have scenarios for trust relations and
(missed)

CA: next steps: discussion on the list
SVS: will be there in the afternoon to discuss

ASSA Abloy presentation

Göran Selander / Marek Serafin / Kamil Kiełbasa presenting.

MS: from ASSA Abloy. Early adopters of EDHOC. Have first real product
hitting the market using EDHOC. EDHOC between mobile phones and embedded
side. All based on CoAP, OSCORE, and EDHOC. Kamil published well written
C-library for EDHOC at Github.

Marek: My own implementations not published yet, running 3 initiatives:

1. Product we develop either embedded-embedded or phone-embedded
   communication, trying for EDHOC+OSCORE everywhere. Personally
   involved with project where phone talks to embedded; Swift library
   to be published soon.
2. Also porting some to TypeScript: A test / interop server. Many
   divisions and integrators eventually try to get onboard. Want to get
   it to state where someone can just use the server to validate their
   implementation. On https://edhoc.me/. Screensharing diagram of
   session management available through CoAP and HTTP (allow different
   types of certificates (X509, CCS)). Session handle created with that
   calls unique EDHOC through CoAP or WS (no CoAP), and then maybe (if
   time) continue OSCORE when using CoAP. Will be published and open
   source. After running CoAP, read out information in session (like
   test vectors). Reason: had challenges when mixing connection
   identifiers with sender IDs. So far, private project, not company
   bound.

If interested to contribute can invite to the GitHub repo. Plan to work
during summer holidays.

GS: what ways can others contribute?
MS: Will probably not cover all suites, focusing on day-to-day relevant
works. CBOR certificates will not be there from the start. PRs welcome.

GS: if someone has their own implementation, can add to edhoc.me?
MS: For now I wanted to start with edhoc.me being a server supporting
forward and reverse flow. Would be nice if edhoc.me could run client to
some kind of responder. That's one future possibility. Could also be
facade to other implementations.

CA: easy approach for more implementations, I could take a look at
interface for sessions, and tack that interface to other
implementations. And have other instance that you can run tests against.
Just copy your interface.
MS: if publicly open reference and compatibility (lost part here) good
to align and run interop and fix things. Can run reverse flow from your
side to make you responder. Just running EDHOC against reference that
will allow you to test and develop new implementations.
CA: (thumbs up)
MS: Most trouble we had was lack of references, of large sets of test
vectors. Didn't know which one is there reference one. Session report
will give test-vector-like results.

GS: Timeline on products being available?
MS: 2-3 months. Centrios lock.
MS: And there is now an initiative. Within a few years, hopefully all AA
products will use EDHOC+OSCORE+CoAP. And devices with secure and
unsecure side, now also talk CoAP/OSCORE/EDHOC.

MS: EDHOC was perfect use case for us. If want to change part like
outside of lock, just by replacing and using correct credentials, inside
and outside would auto-enroll.

Kamil presenting:
(sharing screen of libedhoc documentation)

https://github.com/kamil-kielbasa/libedhoc

KK: Currently working on documentation(?).
KK: Idea was to have simple API, with access through a context, no
access for user to key. (For some parts using PSA library). Looking to
interoperate more to see the unhappy paths.

MS: lake/edhoc repository would be a good place for more test vectors,
also different and negative scenarios.
GS: Should bring that request to WG.

CB: Formally it's not a WG activity unless writing an RFC, so idea to
just add them to a repo is exactly the right way.

MS: our implementations are limited to certain suites and credential
types. Marco's cover's different types. Great we create these vectors
with other implementations and configs

GS: good to set up GitHub issue

CA: looks like awesome work, thank you!

MS: thanks to aiocoap we found good issues in our OSCORE
implementations. Only implementation checking if response is also
OSCORE.

CB: would make sense to find a date in about month from now to have
another synchronous online thing where we all meet?
MS: Would be great.