CoAP road map

[chrysn]

This is the big tracking issue for all things related to the CoAP+security components that should be part of RIOT-rs.

The big picture

Having a CoAP server running should be a feature that's available for both application and system components -- if SUIT update is enabled, there'd be a resource to POST a manifest to, if sensors are configured to be exposed, they're there, link-layer security can use CoAP to bootstrap (RFC9031), and if the application adds resources, they go in too. All these should be protected unless explicitly configured otherwise, with OSCRE (RFC8613) and EDHOC (RFC9528, yay, it's published). Big steps are therefore:

Technical components

• CoAP server can run
• CoAP client requests can be sent
• Modules can describe their resources for a CoAP server to be spawend automatically
• CoAP requests are processed through OSCORE
• The credentials associated with a request (from OSCORE contexts) are available to the resources
  • this may be a very hard (and thus late) step because the current shape of coap-handler does not allow passing down data
• Resources don't need to care about the credentials because there are global rules for what is allowed
• EDHOC exchanges are processed into OSCORE contexts
• Credentials for EDHOC exchanges are verified using a configured AS key
• EDHOC exchanges are initiated on demand
• Credentials for EDHOC exchanges are obtained on demand from an AS
• Configuration (eg. the AS identity) can be provisioned through 3-party EDHOC (authz)

(For the time being, check marks indicate what works rudimentarily; at one point I may revert this to empty and then it'll indicate whether things are not just working but usable and good)

Usability components

Demo and document for

• sensor access from a host
• secure sensor access from a host
• new hosts accessing the sensors securely
• linking sensors and actuators between two boards (dynlink?)
• securing that link (not sure how token transfer happens there -- user obtaining a token and relaying the token response? user telling the AS that the client is authorized to do what the dynlink says?)

Sequence and granularity

As a tracking issue, all those will be turned into issues over time. I'm not sure we'll get to all of those, and others might be added, but that's the rough plan.

I don't plan to do them all in full sequence -- that'd delay interactions with the rest of the system, and I'd like to have (for example) credential configuration going way before everything with OSCORE is polished to the point where EDHOC gets added. Thus, I'll start small with #225 and quickly add losely tacked together OSCORE and EDHOC components, getting everything in a very rough state before starting to make it well-managed piece by piece.

Dependencies

• I'd rather not write a CoAP server bespoke for embassy-net or smoltcp and rater hone the one based on embedded-nal. This requires embedded-nal support for embassy-net, and while that is formally there, the only parts that are really implemented as of now are embedded-nal DNS (which is basically a simplified getaddrinfo). So we need
  • net/UDP: Implement embedded-nal-async traits for UDP embassy-rs/embassy#2516 for which I have a draft PR net/udp: Add some embedded-nal-async UDP traits embassy-rs/embassy#2519 -- a subset of that is net/udp: Relay full UdpMetadata instead of only remote endpoint in poll_ functions embassy-rs/embassy#2790
    but that depends on smoltcp:
    • UDP: Read and set local address on unbound sockets (IPV6_PKTINFO style functionality) smoltcp-rs/smoltcp#903 / UDP: Store local and use local address in metadata smoltcp-rs/smoltcp#904 (comment)
• Random number generator support #231

[chrysn]

Part of the whole story will be setting up your own minimal AS. (Or, really, generic trust anchor, because SUIT firmware signing needs a key too.) It may make sense to have some very minimal piece of software around that is documented to not be production ready but can hold the relevant keys for long enough that you can migrate to a "real" authentication server at some point.