IOTOPS @ IETF 115

Tuesday, November 8th, 2022
13:00 UTC
1.5 hours

Meetecho:
https://meetings.conf.meetecho.com/ietf115/?group=iotops&short=&item=1
Jabber: iotops@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-115-iotops

Chairs: Alexey Melnikov and Henk Birkholz

Note takers: Marco Tiloca
Jabber scribe: Warren Kumari

Administrivia

HB doing introductions.

Device Schema Extensions to the SCIM model

https://datatracker.ietf.org/doc/html/draft-shahzad-scim-device-model-00

(Moved up as first item)

Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-iotops-scim-for-devices-00

EL presenting

EL: The work will be discussed on the SCIM list; it's not for IOTOPS to
adopt. Reviewers/authors/implementations are needed. Goal is to consider
adoption in 2023.

BM: How is SCIM authenticated?
EL: It's RESTful, you authenticate both endpoints. For client
authentication, you do whatever HTTP allows you to do.
BM: So, transport-based authenticated?
EL: Yes, though SCIM takes care also of authentication of transferred
documents.

MCR: Is the place where to provision to the new owner?
EL: Depends on the model, it can be the manufacturer.
MCR: There's a chain of custody involved. The challenge is to ensure
that the chain is actually as expected from the point-of-view of the new
owner. It's a big issue, I suspect bigger than the SCIM WG and I suggest
to bring it back to IOTOPS regularly.
EL: We'll take your advice.

Erik Nordmark: What was the thought process in the SCIM WG?
EL: In healthcare, there's a lot of information exchange with support by
the cloud, together with control functions. Another examples is nurses
stations, for practioners to plug device in and having a smooth
communication to the hospital follow.

A summary of security-enabling technologies for IoT devices.

Draft for possible WG adoption:
https://datatracker.ietf.org/doc/html/draft-moran-iot-nets-02

BM presenting

Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-iotops-mappings-of-baseline-security-requirements-to-ietf-technologies-00.pdf

BM (p4): The main thing is mapping IoT security requirements from
ENISA/ETSI/NIST into the work in the IETF, without reinventing those.
BM (p6-7): Have requirements categorized as procedural, architectural
and technological. The different, broad ENISA categories can be mapped
to IETF work.
BM (p8-9): Only gone through the ENISA requirements so far, I will
continue with those from NIST. Looking for co-authors and help/input.
This should be helpful especially for security officers that can perform
a sanity check on considered technologies.
Jasper Pandza: Was rapporteur of ETSI EN 303 645 ("Security Baseline
Requirements for Consumer IoT"). ETSI has been carrying out significant
work in the consumer IoT space. Alongside the main requirements standard
(EN 303 645), there are two documents worth referring to: TS 103 701
(assessment specification on device vs. requireents) and TR 103 621
"implementation guide" (40 pages with implementation examples).
HB: Would you be able to contribute and help Brendan?
JP: Yes, will give pointers and input. (All is available for download
via https://www.etsi.org/technologies/consumer-iot-security)
BM: Good to know there's something out, I'd guess not all requirements
are covered anyway.

HB: We think of adopting this document, we'll go for in-room consensus.

"Please raise your hand if you think ... (=> that this is good for
IOTOPS)"
Raise hand: 33
Do not raise hand: 3

EB: You mentioned potential gaps.
BM: I haven't seen much on onboarding guidance. Overall coverage looks
good, but something is missin altogether in terms of guidance. If I miss
anything of that kind, please tell me.
HB: Again as a call for contribution.

HB: Any comment from the "Do not raise hand" people?
Matthew Gillmore (on chat): The scope does not seem clear to me. That is
why I didn't raise my hand.
BM: The scope is precisely about doing a mapping. The scope is weak now
about which requirements to adopt and map, I welcome input. And if we
see any gaps, we provide guidelines ourselves or we highlight what is
missing.
Adnan Rashid (via chat): It's still broad scope.

HB: We'll start a WG Adoption Call.

"Power of Attorney"-based onboarding

https://datatracker.ietf.org/doc/html/draft-vattaparambil-iotops-poa-based-onboarding

Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-iotops-power-of-attorney-based-device-onboarding-00.pdf

Sreelakshmi and Olov Schelen presenting.

We'd appreciated review and comments of the draft.

Behcet Sarikaya (on chat): PoA onboarding could take long time, all
application layer heavy operations

Vadim Cargaser: You said we need to integrate with OAuth. How is it
different from OAuth itself?
OS: You sign the PoA beforehand to be valid for a long time. It's
scalable onboarding.

BM: The signatory registry seems to overlap with what is done in the
SCIT WG. Also, what is the difference between this and key delegation as
done in the PKI where I have a root CA signing a certificate?
OS: This is more about authorization. You can still use a PKI for
public/private key.
BM: How do you handle revocation of the PoA?
OS: Always hard in decentralized systems. The PoA repo has some
centralization and improves the possibility to revoke; it's still under
studying.
BM (on chat): I think that for PoA Onboarding, the best answer for
revocation is probably a let's encrypt model: 1-day tokens. When they
expire, they're no longer usable. That way you don't need revocation;
you just don't renew.

Erik Nordmark: The flow compares to something like ??? device
onboarding. How are things related?

ED: You're using JSON web tokens, but there are also CBOR web tokens,
even if not specific for onboarding.
BM (on chat): Please no JSON in IoT.

MCR: You cite Intel in the draft but not FIDO. Please look at what
happens in the ANIMA WG. You are reinveinting 3 or 4 wheels, so you
should consider converging to already existing file formats. What do you
mean with "no ownership transfer is possible"?
OS: In the consumer market, there's probably no need for a PoA. Instead
we heard it from the mining industry, where the original manufacturer is
not trusted and things have to be onboarded in a scalable way.
OS: The transfer of ownership remains with the sub-contracting.
MCR: Sounds like you want to bring my phone in your network without
owning it. So it's more about access control, not onboarding.

Matthew Gillmore (on chat): +1 to Michael's comment about re-inventing
the wheel

Behcet Sarikaya (on chat): onboarding is a step before bootstrapping

EN: Not sure if there's real difference from giving limiting access
rights to devices.

OS: Should we make an update to the draft and come back to IOTOPS?
HB: Yes.
MCR: Yes.

Attested TLS

https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-02
https://datatracker.ietf.org/doc/html/draft-bft-rats-kat-00
https://datatracker.ietf.org/doc/html/draft-ftbs-rats-msg-wrap-01

Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-iotops-attested-tls-00.pdf

HT presenting

HT: This spans over three documents.
HT: This presentation focused on attesting the status of the client, but
it's possible to attest also the status of the server (e.g., in the
confidential computing use case). Ongoing supported prototype effort.

EN: When does the identity key actually change?
HT: It's an ephemeral key, unlike in regular client-side authentication.
This is not signed by the CA, but instead by a key available to the
Attestation Service.
EN: Do you do this at every device boot? Would the key change then?
HT: For the onboarding case, you run this every time you need. For the
confidential computing case, you run it every time you interact with the
platform.

DT: If you never do the passport model, it may still be ok with the
background check.
DT: On page 4, you should check how to use this to do attestation in the
other direction.

CB: A TLS connection can go on for a long time. What if you need
freshness throughout this connection?
HT: So in case you want to re-run this in the same connection?
CB: Yes.
HT: There's a way to but it has limitations.
CB: I'd like to see an example, you may have other things going on in
the current connection that you don't want to tear down just for doing a
new attestation.
HT: We'll look into it.

LWIG Status

CB presenting

Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-iotops-lwig-00.pdf

CB: Overall proposal to pass the work on two LWIG documents to IOTOPS,
as still compatible with the IOTOPS charter. Need to get the AD in the
loop.

Behcet Sarikaya (on chat): I support it lets do it.
Erik Kline: As LWIG AD, I support this.

Erik Kline: Leaning towards closing LWIG.
Matthew Gillmore (on chat): +1 to the AD's comments about closing LWIG

HT: Maybe the LWIG WG ran out of steam not because of the WG itself but
because of the documents, with only the authors interested in them.
CB: To be judged, but it's good to complete the work on those documents
as useful to work on.

HB: Raise your hand if the terminology document can be completed in the
scope of the IOTOPS WG
Raise hands: 30
Do not raise hands: 2

CB: Those who said "Do not raise hands" can contact me, I'm interested
to hear their reasons.

AOB