# IOTOPS @ IETF 118   {#iotops--ietf-118}

Thursday, November 9th, 2023  
16:00 (Prague, UTC+1)/15:00 (UTC)  
1.5 hours

Meetecho:  
https://meetings.conf.meetecho.com/ietf117/?group=iotops&short=&item=1  
Notes: https://notes.ietf.org/notes-ietf-117-iotops

Chairs: Alexey Melnikov and Henk Birkholz

Note takers: Michael Richardson,

17:00 Administrivia  
 (5 min; chairs)

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

 (10+10 mins; Brendan Moran)

~~17:25 Comparison of CoAP Security Protocols  
 https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-03

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

BM presenting.

BM (p2): Surprise: We didn't cover all bases.  
BM (p3): Consumer -> different DPR requirements than in industrial  
BM (p4): "Baseline" ... but a lot in there (not sure what they left
out).  
BM (p4): Are we done?  
BM (p5): Help, or state what's needed; let's get it done.

HB: Asking for revierwers?  
BM: Yes.  
Hands in the room: Hannes  
(6 people in show-of-hands tool and none of them was Hannes; Alexey is
one of the 6)  
REVIEWERS: Hannes, MCR, Wei,   
Wei Pan: Raised my hand. Have another project in ETSI Cyber.  
Wei: there are ETSI requirements in this, and happen to have another
project there, and will advertise this document there.

HB: Please summarize updates on list.  
BM: Yes. Didn't want to do delta on slides.

17:40 TLS/DTLS 1.3 Profiles for the Internet of Things  
 https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-08

 (15+5 mins; Hannes Tschofenig - HT)

HT presenting.

HT (p1): It's not a doc of this group.  
HT (p2): summarizing. 7925: What type of credentials, what types of
extensions etc., and different organizations' input. Now updates for
1.3; shorter b/c core addressed things.  
HT (p3): More X509 now. With mutual authentication, populating fields in
CA certificate and subordiate etc. for the device.

HT (p4): Cert profile did and does focus on ECC. Used to use 802.1AR
terminology, now uses this more. In particular LDevID, as IDevID
guidance is already available in other places.

HT (p5): Selection of items where feedback appreciated.  
HT: Show of hands -- who has deployed X509 in IoT?  
(many)  
EL (Eliot Lear): It's *required* in matter that you have.  
HT: Time trouble. Manufacturers use infinitely valid certificates.
Implication is that this is necessary for rest of chain -- and trouble
with revocation (and not mandating OCSP etc b/c nobody uses them). Soft
language on updating certificates.

CA: unreliable time, let's sync on t2trg-raytime  
HT: Possibly different things to suggest, also roughtime.  
EL: On OCSP, do we have idea of who should do OCSP stapling?  
HT: Idea was that server sends stapled. Issue: devices have few
communication partners. When stapling fails, talk to device mgmt srv. If
certificates have issues, what do you do, how do you recover?  
HT: Some stacks don't even support OCSP.  
EL: (...) give more guidance. Eg. in EAP-TLS, if you don't have IP
connectivity, what do you do?  
MCR: Story for root CA expiry time is different between IDevID and
LDevID. For IDevID you need infinity. On other side, you can roll root
CA and resign provided you can get trust anchors out. Subordinate CAs
can even resign end entity certificate. It's conceivable to do that.  
EL: "conceivable"  
MCR: On operational side (EST), there is ages old thing on
new-signs-old-and-old-signs-new, mechanism is out there and in EST. It's
even in EST-over-CoAP to do it efficiently. It's possible, and rather
than "infinite on LDevID", we could have short-ish lifetimes. Problem is
real. Document the tussle.  
MCR: Talked to 802.1AR authors. It's weak w/rt what goes into cert. We
could do an IoT profile in the IETF of 802.1AR, esp. where do product
S/N go etc. Case of "unless someone says please adhere to RFCxxx, nobody
will fix it"

HT: When you don't have a time source, may run into self-inflicted
problems from short lifetime certs. Probably distinguish between real
constrained devices v. Linux style IoT devices.  
HT: On 1AR, not sure I have appetite for that. Will come back to that.

GM (Giridhar): Ellaborating on comments sent on chat window:

> Re: cert validity. Cert revocation has for pre-stored certs that have
> no maximum validity has been solved without CRL's already. Many
> products exist on the market already.

GM: (sorry not understanding well) Can't compell an IoT device to not
operate. Need alternatives for non-IP-connected devices.

HT (p6): key usage: how to handle in case of updates to the application
protocol.  
Recommendations on how to use in Root cert, Subordinate CA Cert, End
Entity Cert.  
Question to audience: (didn't get, no answer from audience).

HT (p7): Had assumed could put something for subjectAltName (SAN), and
people would use it -- turned out that didn't work, now lifting
requirements. Many types of identifiers available today -- what have
people used (and which bring value)?  
AM as participant: elaborate on "sAN must not contain multiple names"  
HT: This is for device itself.  
AM: But you can use different types. The way it's written, you have to
pick one from the list.  
HT: That's not how we thought it.  
AM: But can have sAN of different types?  
EL: Yes, but only one of each type.  
HT: Need to check.  
MCR: Interesting to understand use cases. If not doing DNS IDs and no
X50 serial number in DN, what do you put in other places? One reason for
multiple names of same type is b/c you use the same IDevID with many
onboarding protocols. So far, know of nobody who said "MUST put DNS from
ABC" and others "MUST put DNS from not-ABC" -- could trip over that when
building L(?)DevID that satisfies everyone.  
HT: How do we get that information? Look at specs? Sadly, reality
sometimes disagrees (subset being used, other things being used). Not
sure how this is actionable.  
MCR: Could create registry, and poke people to put things in there.
Apparently not mandatory (b/c X.509), but do something to imply people
should come here given that we mantle PKIX thing. (??)  
HT: DN, what do you use?  
ACTION \{david navarro) DN: Would need to ask colleagues.  
Dave Robin: My usage is simple. Encode URI using our own URL scheme and
thus identify BACNet devices. Every cert has `bacnet://1234` with device
ID. Started with GUIDs and all fancy stuff, but we already have 24bit
IDs and they are unique. An assigned number.  
MCR: It's an LDevID  
DR: But in a URL.  
HT: ACTION please send to the list.  
HT: Maybe MCR's registry is not that bad. Otherwise hard to maintain
list.

HT(p8):  
Show-of-hands: Reviewers  
REVIEWERS: Thomas (also send examples of different domains), Dave Robin,
MCR (can again), Eliot (already a GitHub issue)  
EL: There's comment in draft on TLS1.3 about PFS in all suites. That's
not true, 9150 suites still don't (Static-DH crypto ... not recommended
but there and for a reason). Sit down with Nancy and Stephan Fries (?),
probably worth comments. Not to encourage it in all cases, but specific
cases where was necessary.  
HT: MCR also had comment on unencrypted(integrity only); might fit in
the same bag.

HB: Happy alone or would like more contributors?  
HT: Currently Thomas Fossati, MCR, myself. Are open, but decision of UTA
chairs.

HT(p9): Shepherd? If interested, talk to us or UTA chairs.

HB: elaborating with shepherd's duty: Keep track of document
development. Shepherd may poke people, UTA chairs (where it's at), ADs.
It's not that difficult.

## 18:00 An Application Layer Interface for Non-IP device control   {#1800---an-application-layer-interface-for-non-ip-device-control}

        https://datatracker.ietf.org/doc/html/draft-brinckman-nipc-00
        (15 mins; Eliot Lear?)

Bart Brinckman presenting.

BB: authors represent network and application side.  
BB (p2): Problem statement. Each application provider bring their own
infrastructure and API to bridge together devices across different radio
technologies.  
BB (p3): Solution approach. Common API across several radio
technologies.

BB (p4): Non IP Control (NIPC). Explained diagram.

BB (p5): Diagram with example of BLE Advertisement (broadcast) from
device. Sequence:

1.  Application Onboards and Registers new Device to Access Point.
2.  Device sends advertisement to Access Point.

BB (p6): Example: Attribute r/w from BLE. Detailed diagram with BLE
device A, Access Point, Application. Maps BLE commands to REST verbs.

BB (p7): Example: Attribute r/w from Zigbee device. Onboarding request
(like shown on p5) and mapping of Zigbee requests to REST verbs.

Wei Pan from ?Huawei: Silo is pain point of enterprise networks.
Comments: 1. It's "Non-IP" and don't think IP is reason; 2. not familiar
with SCIM but think it's good. What are cost / limitation / advantage /
disadvantage of that?  
BB: Advantage is that it's used in industry at scale. Known to scale,
active community. Looked at various REST APIs, but wanted to uplevel b/c
BLE REST API is not being used. Needed something meaningful outside of
single radio techs.  
MCR: Clarify "GET attribute" -> data attr response (p7). What encoding
used? Zigbee encoding? (BB: Hex). Whatever ZigBee spec says? (BB: Yes).
MCR: So Application has to know how its protocol work. So may
characterize it as Zigbee-over-HTTP / BLE-over-HTTP. May contribute to
more understanding. As an aside, You give each device an individual UID
through gateway.  
BB: Nice idea, UUID right now.  
MT: Talked similar in IoTops on industrial IoT.  
MCR: Can we adopt this here based on charter? (?: Why not?) We were
excluded from doing some protocol stuff, but this may fit. Also, with
ASDF hat on, convinced it should not be in ASDF, but need home for it.  
?: Someone should look at chrarter carefully. Seems we can squiggle it
in.  
HT: Not new, tunneling has been done. An upcoming challenge is that
companies selling the gateways didn't do that on accident. It's a
control point for them. Getting that away is good for consumers, but
will be rough. (Business question not engineering) 2nd thing: OMA
published "gateway specification", may give ideas on how others solved
it.  
BB: Most people deploying controllers are not inrastructure but
application business.

## FIDO Device Onboard (FDO) update   {#fido-device-onboard-fdo-update}

Slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-iotops-securing-fdo-credentials-in-tpm-00.pdf

Geoffrey Cooper presenting remote

GC (p2): More adoption now (eg. Dell Edge)  
GC (p2): Spec steady for a while; app notes answer questions.  
GC (p2): Interop testing happening.  
GC (p3): Overview; "voucher": Different from RFC voucher. Separate
object, similar kind of purpose. Voucher followes paperwork, device goes
to installation. Rendevouz services hardcoded in the device.

GC (p5): Comparison to IETF work. (row 2) Addresses that organization
doesn't need to do any of its network. (row 3): allows incremental
routing. (row 5): If we had lighter TLS as now is there, might have done
more.

GC (p6): *If* you have TPM, *how* to do it (so it's the same across
vendors). Thus, can be in TPM already from vendor.

MCR: 1. Does it have to be TPM or is Secure Element sufficient?  
GC: Spec is TPM dependent; other SE can do other things.  
MCR: NIST(?) effort is about standardizing initial credentials in SEs
and TPMs (and processes around factories). Would like to have FDO
involved for more variety in opinions.

HT: Please point to document on list.

(note taker chat, IIUC:)  
MCR: aka brski-cloud is IETF version of rendezvous service :-)  
(CA->MCR: Can probably do this if .arpa name resolves to rendevouz
service...)

AOB