LAKE hackathon project

[chrysn]

Some of us (@kaspar030, @ROMemories, @emmanuelsearch, @chrysn) will be at the Paris LAKE hackathon co-hosted with T2TRG.

What precisely do we want to do there?

Hackathon project

• Progress the https://github.com/future-proof-iot/RIOT-rs/issues/226
• Further the Lakers integration

Side meeting

Investigate gaps in what we want to achieve and what is specified (originally from the lower-most items of the "Usability components" list of the CoAP tracking issue)

• In the area of M2M automation: Two devices are configured by some configuring agent (presumably an unconstrained system), and are configured to perform some automation task between each other. For a simple example, a heating controller is configured to GET (observe) a temperature sensor. Ex ante, neither is authorized to interact with the other. Configuration might happen by the configuring agent telling the heating system the URI to get the temperature from through some configuration mechanism, or even through a dynlink -- but that only conveys the URI and is missing

  • configuration that allows the client machine access to the server machine, and
  • configuration by which the client machine recognizes the authenticity of the server machine (safe to say the address may be an IP literal, and the server machine will not have a browser-style certificate chain to prove that name).

  How does the configuration tool tell the the AS that some device as a C is to be given extra privileges? Within the ACE framework / the CWT ecosystem, sketched options include (with 3. looking most promising):

  1. The tool obtains a token that allows some delegation, wraps it somehow, and passes on that token to the client machine. While this sounds simple, that wrapped token is associated with a key of the configuration tool, so it'd first need something like a signing key enrolled in the AS, sign the token with that, and it all gets very complicated.
  2. The tool could, through some AFAICT not yet specified interface, ask the AS to grant some extra authorization to the client machine. This requires a new interface for delegations, and requires the client machine to be enrolled as an ACE client with the AS and to act as an ACE client (not unthinkable for a constrained system, but also not ideal).
  3. The tool could ask the AS for a scope-limited token with the client machine's cnf. It would transfer the full token response (including rs_cnf) to the client machine. The client machine could not verify that this is coming from the AS, but may not need to (after all, different ASs could be involved) -- it merely takes that response as metadata on the link that the tool is apparently authorized to perform (it may set any URI, but it chose to back the URI it set up with some ACE details).

Relevant links

• Hackathon project list
• Side meeting list

[chrysn]

Some notes from chatting with @marco-tiloca-sics:

1. is indeed overly complicated.
2. may not be too bad on the device as I thought. Rather than storing the token and the token response on persistent memory, the device receives from the configuration tool the AS token URI, the CRED_R of the AS and the scope/audience to request (which may be quite small if the configuration tool agrees on a compact phrasing with the AS). Then it just needs to run an EDHOC exchange with the AS (or one OSCORE follow-up request) every time the token expires, rather than doing the same as drive by the configuration tool. The EDHOC exchange can serve as proof of possession, which AIU is an open ToDo item of the ACE EDHOC profile (@gselander, please correct me if that is not so). This "just" needs an ace-as-admin document ;-) -- at least enough of it that the configuration tool can state that there is a new C with the credential of the client machine, and a means of granting some scope on an audience that the configuration tool has to that new client (possibly using a more compact and more client-friendly phrasing of the scope).
3. may not be aligned with ACE because the AS will require proof-of-possession of the credential to issue a token (even though I don't quite understand why that is required -- the configuration tool has the authorization, and there are good arguments for delegation). Also, it is not as simple as hoped because the token will often be short-lived, and a new token will need to be sent time and again.

---

If we accept the alternative flow of the AS installing the token in the RS (or the C has easier means of receiving the updated token), there might be the extra option of doing something 3-ish once, PoP'ing the credential (eg. by running some authz-style dance between the machine client, the configuration tool and the AS), and then setting up the AS to issue new tokens automatically to the RS (or offering them on request at some URI; after all, they are encrypted and just updated regularly), this will need further consideration.

---

Some documents may be relevant:

• https://datatracker.ietf.org/doc/html/rfc7591 on how clients are added dynamically in OAuth (sounds mighty complicated)
• https://www.ietf.org/archive/id/draft-vattaparambil-ace-wg-poa-device-reg-00.html on PoA device registration This looks like the solution if we go with 2. It is more of a problem statement / sketch so far, and will need interfaces worked out. (Also, it is leaning toward DTLS, and assuming an unencrypted pre-flight rather than the configuration tool knowing the scope, but those are details that should not impede the process).

[chrysn]

While the project is being tracked here, I can just as well upload slides: missing-pieces-slides.pdf (last slide represents what was scribbled during the meeting).

[chrysn]

During the breakout session, new slides summarize the side meeting findings

[ROMemories]

Closing as the hackathon is over. @chrysn feel free to re-open or open other related topic issues if needed.