IOTOPS @ IETF 117

Wednesday, July 26th, 2023
15:30 (San Francisco, UTC-7)/22:30 (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: Warren Kumari helped by Michael Richardson

15:30 Administrivia
(5 min; chairs)

A summary of security-enabling technologies for IoT devices (Brendan
Moran)
https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-summary-00

• Slides
• Maps security reqs from existing standards docs to IETF
  technologies.
• Directs implmentors to standards based solutions to their security
  issues.
• Makes implmentors aware of the issues they might encounter when
  making IOT devices.

• Maps security requirements between differnt requirements docs...

• Plea: I want a co-author... please...

• Is it ready for WGLC?

• Bob: I'm doing a simpler doc on my own. This should not become an
  RFC; it should be, and remain an ID.

• Eliot: I will review and contribute. I am not necessarily qualified
  to be a co-editor though.

Actions:

• Proposal that this become a living document, rather than an RFC.

Comparison of CoAP Security Protocols (John Mattsson)
https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-02

• Slides
• List of changes from -00 to -02
• Early IoTDir review by Russ Housley

• Next steps:

  • Address IoTDir comments from Russ.
  • Submit -03.
  • All other issues and comments have been addressed.
  • More reviews, WGLC?

• Discussion (Timestamp: ~0:25):

  • Alexey: Do we need to wait until cTLS published?

    • Could publish now or wait... cTLS is probably the long pole
      in the tent...

  • Alexey: We will check with chairs of TLS

  • Henk: Please let us know if you have issues addressing Russ's
    comments.

Device Schema Extensions to the SCIM model (Eliot Lear)
https://datatracker.ietf.org/doc/html/draft-shahzad-scim-device-model-05

• Slides
• Mostly background, I was invited to give updates on the draft...
• Goal: Abstract the provisioning mechanisms
• The concept: Enable as few invarients as possible
• Partners providing IoT devices will call into SCIM

• List of schemas

  • BLE, Zigbee, Thread, etc...

• Status update

  • Some issues to address
  • Hoping to release OSS code before end of summer

• Discussion (Timestamp: ~0:35):

  • Hannes: Architecture: I don't really understand how you want to
    use the schema...
  • Elliot: You picked the hard one :-P {Reference to slides -
    minutes taker got sidetracked into looking at pretty diagrams
    and lost track of discussion :-( ). Something something push
    voucher. General agreement. }
  • Authors didn't want to create a new onboarding mechanism.

BRSKI-CLE: A Certificateless Enrollment protocol in BRSKI (Lei YAN)

https://datatracker.ietf.org/doc/html/draft-yan-anima-brski-cle-00

• Slides
• Gateway cares about whether the IoT device is legitimate rather than
  who is the IoT device.
• Requirements of the authentication mechanism: Lightweight, scalable.
• Description of existing asymmetric cryptography based authentication
  mechanisms
• Description of certificateless authentication mechanism
• Introduction of BRSKI-CLE
• Description of enrollment protocol
• Discussion (Timestamp: ~0:46)
  • Hannes: First slide - problem statement. I'm not sure how this
    solution shows that the device is legitimate.
  • A: Device will be authenticated by BRSKI virtual {inaudible}
    certificate after authenticated by BRSKI. Legitimate is based on
    previous BRSKI authentication.
  • Hannes: Trying to replace "who the device is" to "legitimate
    based on BRSKI"? Doesnt this require changing all of BRSKI. Are
    you still using TLS?
  • A: We change the {inaudible} protocol.
  • Hannes: This shows TLS as bad, but this as much better... but
    you are still using TLS...
  • A: We are only changing the enrollment protocol. In steps of
    BRSKI there is {inaudible}. After enrollemnt we use credentials
    to authenticate each pther.
  • Hannes: Do you use CSR with extensions? I don't get the new
    functionality...
  • MCR: Yes! It starts with BRSKI, and so it starts with IDevID,
    and it could do remote attestation, if we define that. This
    proposal is really just about an alternative enrollment after
    BRSKI has setup the BRSKI-EST. But, afterwards, it's custom
    crypto instead of LDevID.
  • After this you get EST and do enrollemnt on that. WK: MCR,
    please help clarify what you said, I missed much of it. After
    you are provisioned, you talk device to device, and then you use
    raw public keys with something like OAUTH.
  • Bob: Over 20 years, we've seen things like this being put
    forward. Some statements made about scalability. I've never seen
    it scale in a safe way... Central store is a dangerous thing...
    As far as lightweight -- we are addressing separatly...Leery of
    IBC will need to have very serious review. The model is scary...
    This might be good in a small scale (e.g home) environment, but
    I'd be scared in e.g a sensor network.
  • A: Security of our scheme - we will go to the WG to promote
    algorithm in this draft. Already have some security proofs of
    our protocol.
  • Bob: Initial step is the OOB step, this is semantis.
  • Hannes: This needs to be framed in a more neutral way.