T2TRG 2023-05 security interim

Intro

Carsten Bormann (CB) doing introduction.

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-t2trg-01/materials/slides-interim-2023-t2trg-01-sessa-chairs-slides-00.pdf

Amplification attacks using CoAP

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-t2trg-01/materials/slides-interim-2023-t2trg-01-sessa-amplification-attacks-00.pdf

John Mattsson (JPM): presenting.

JPM (p2-3): Overviewing changes, mostly based on comments from Achim
Kraus and Sultan Alshehri.
JPM (p4): Planned next steps. How to refine the scope of the document?
Raise awareness of amplification attacks? Propose mitigations? More
should be said about the mitigation. Confirmed that no further specific
DDoS attack incidents will be covered. After taking care of this, I
believe the document would be ready for requesting publication.

CB: when you say "describe mitigations", there already are docs out
there about this. Is it about describing or pointing to relevant docs?

JPM: That needs some analysis. We first point to existing ones, and
comment on their effectiveness. We might to add new ones if needed. Not
much was said on multicast when this started, now more is said on that.
More should be said also related to
draft-ietf-core-conditional-attributes.

CB: asking because danger we end up writing BCP here. Not the intention
of RG doc. We should document the state of the art, including specs out
there, and considerations for future specs. But should not be
recommending stricter limits for something. If there is work to be done
at IETF, we should identify that and see that it's started.
JPM: won't have RFC2119 language here. Agree here.

Michael Richardson (MCR): The document looks shorter than I thought.
What about amplification when you use Block-wise?
JPM: Not considered yet. It's more that you find attack vectors and then
you add them to the document.
MCR: I can't think of any, but it would be good to know that
transferring a big payload is fine. Would be good to have more specific
than just "amplification" terms. Good to have common understanding of
attacks. Readers would be reassured that this and that are actually not
a problem.

JPM: open for suggestions, for names etc. Feel free to contribute
MCR: OK

JPM: need to separate when using / not using security protocol. Slide 5
gives overview of mitigations discussed in the draft. Plan is to add
more info on mitigations and how effective they are.

Mohit Sethi (MS): I find the document useful, same for the document in
CoRE on attacks against actuators. Is there any consideration about the
Resource Directory when responses can be much larger than the lookup
requests? Or when you also use Observe?
JPM: don't know but might be good to investigate. Can you open issue and
describe at high level what is your thinking? Can help analyze and see
if there should be something specific
MS: Yes, sounds good.

JPM: It seems we have rough consensus on the way forward.

CB: have several items we can pick up after meeting. Will discuss
discovery at the end of the meeting and Mohit's comment is interesting
in that context as well.

Terminology and processes for initial security setup of IoT devices

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-t2trg-01/materials/slides-interim-2023-t2trg-01-sessa-draft-irtf-t2trg-security-setup-iot-devices-00.pdf

MS presenting.

MS: overviewing recent updates (document title; off-list feedback on OMA
to be addressed in the next version).
MS: The document covers terminology on initial setup of IoT devices.
MS (p4-5): showing existing terminology across different documents.
MS (p6): list of considered protocols; no feedback yet on what to
remove/add, please provide feedback. No ambition to have it exhaustive,
but at least fairly representative.
MS (p8): still work to do, plan to do a major revision for the next
version. Before it, we'd like some feedback on what is useful to have
keep for having a high-quality document.
MS (p9-10): For example, more clarity would be better about OMA beliefs.
OMA terminology is more complicated to handle, due to lack of
commonality across different standards. Just used a blind grep of the
standard document to collect terms so far. Not sure it's a good approach
to follow. Maybe it's better to just focus on a few terms from OMA.
CB: I'd want the document to say not only the terms that are used but
also their meaning. This can be about terms from other documents, or
terms that we define anew. Like a dictionary.

MS: Understand, for each standard should list the terms and what is the
meaning. What is implied with that terminology. Would make it a bit
longer but hopefully more useful doc.

MS (p11): Another challenge is also with OMA processes. What should we
say about those? Just what we expect from them to provide/enable? Or
instead a detailed explanation of how the protocol works? I find more
useful the former, also because often the standard does not clarify too
much the expectations from the user, or at least they are not explicitly
listed.

MS (p12): Also, who are the players in OMA? A client/device is not
necessarily a player. What involves a manufacturer or a user, and what
does not? Feedback from the RG is appreciated.

CB: processes, players, and beliefs are the triangle that needs to be
discussed together. In conjunction with "player" we often use "party",
related but may be comprised of multiple players with different states
while being parts of the same party. Who controls but also collected
knowledge of players in the party. Interesting thing is not what are
detailed processes and how does set of players define individual
processes, but what happens before app or devices can do something
useful. Beliefs need to be created and instilled and these need to be
related to players. E.g., device must have key and manufacturer needs to
install that. That's where the three are interesting.

MS: Should we introduce the concept of group of players?
CB: Yes, although I'm not sure of how useful it is. Specific protocol
runs between players. Each party gets assurance the party needs. Party
is the interesting thing in the background, but other interesting thing
for security protocol is that certain player may not represent the
party. Rogue player could compromise the security objectives of the
party. Party controls certain players that hopefully work together to
realize the objectives.
MS: So what would that be in OMA? We'd need an example for some specific
protocol to start with.
CB: good idea to do for OMA since sufficiently complex and stable. Maybe
should find an hour somewhere to do that.

MS: if want to help identify players, processes, beliefs, looking
forward to your (all) comments and PRs. Understand work to be done for
the draft. Hopefully have major revision for the next meeting.

A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-t2trg-01/materials/slides-interim-2023-t2trg-01-sessa-taxonomy-of-installed-trust-anchors-v2-00.pdf

MCR presenting.

MCR (p2-3): Summarizing history of the document and its non-goals.
MCR (p4): the goal is to list ways to provision secure keys, with clear
names for such ways.
MCR (p5-p6): discussions on trust anchors to use in a browser happened
at CA/B Forum and LAMPS meetings. Remote attestation is needed from HSM
about key provenance. For this document, this open for considerations on
the keys, information on those, and how it's reflected in an
attestation. Need also for considerations on (encrypted) extraction and
possible restoring of keys from/to a device by the user.
MCR(p7): Next steps include bikeshedding and advertising the work and
the new terms. Hopefully this can finish by the end of this year.

MS: I'm confused because doc talks about keys and trust anchors but in
presentation also mention CA forum.
MCR: if put public key to device, e.g., to decide what SW can be put
there. Need to keep private key safe.
MS: I'm very much involved in this process
MCR: If put trust anchor in device need to know how management of
private key work out. New addition the terminology attestation has to go
with. Let's have common terminology on this and other area where being
used.

MS: In the devices, keys are usually in fuses.
MCR: that is one method of about 6. Look at device generated key
section. If have one based of PUF (Physically Unclonable Function). Have
symmetric key out of air. Key generated on the device.
MS: Then I was on something else. The key is actually not generated on
the device. Only the public key is put on the device in advance to
verify the signature of a FW update.
MCR: That's fine, then you also have a trust anchor. Different section.
Then have generation of keys that would be 4.1.2 section. About key
generation process. For IDEVID need corresponding private key. How to
generate and where to put that; then can have question if can extract
that and store in a new device. That's the new part.
MS: can send comments on the list
MCR: That'd be great, thanks.

CB: I think this is a useful document. This sort of communication
wouldn't happen otherwise. We have to look at the term definition and
see what is useful to us.

Discussion on discovery access control, secure discovery, privacy-preserving discovery

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-t2trg-01/materials/slides-interim-2023-t2trg-01-sessa-chairs-slides-00.pdf
(slide 11 onward)

MCR (in notes only): is there an ID associated with this discussion?
AK (in notes only): not yet

CB presenting.

CB: We should cover discovery for IoT. That's especially about network
discovery and resource (for service) discovery.
CB: What are the objectives for discovery? A player finds another
player. Confidentiality, integrity, and availability have to be ensured.

CB: Why confidentiality? For example, because of privacy, and for hiding
the presence of something attractive. In general, limit what can
increase the attack surface. This is often simply built on network
security. But who is authorized to do/discovery what? How is that
enforced?
CB: On integrity, that is first of all to prevent spoofing/injection of
discovery information.
CB: On availability, this can be robust against disruptive adversaries,
also when discovery relies on multicast.
CB: Secure discovery can be framed as an authorization problem. One
exact venue is the Resource Directory, but there are more. It would be
good that authentication handshakes happen and are completed before
disclosing anything to non-authorized parties.

CB: Are these interesting and important problems? Should we try to solve
them or just document the state of the art? Any interested people? We
may have a follow-up with interested people.

Göran Selander (GS): is interesting. Secret authentication was unclear.
Have question: we have the CoRE RD RFC [RFC9176]. Some things are
considered there. How does this position with that. Same type of
problems that should have been answered there?
CB: We can learn something from the Resource Directory. That has the
advantage that, when you're using it, you're also already authenticated
to the network. That approach might not seamlessly transfer to early
discovery stages.

GS: have network where have authenticated but not authenticated to
discovery mechanism? What is the difference
CB: If you can't authenticate to the Resource Directory, you're going to
get only limited information. It's a reasonably well understood
authorization model. Less understood whether that information is enough
to arrive at state where you can authenticate with the RD.

MCR: all very interesting and would like to contribute but not sure what
we'll do with it. Is it naming and discussing? Secret handshake has been
tried in DNS-SD some years ago. Sad that work didn't go anywhere. The
industry is not ready for that work. Wonder if we have enough
interoperable IoT that you can go wander in the street to discover
devices. Not sure world is ready for this yet.

CB: yes, that's why RG not WG material. What described is main reason
why doing security is hard. Best way to avoid security problem is to
make the systems not work. Our interest to make things work but if we
run into problems like this once we make things work, would make it hard
to make things work. Good to think ahead of the time.

Milan Milenkovic (MM): answer to question: yes, interesting. Would help
even before write up to identify the scope. Who can discover subject.
Security constraints and what in place. How much to discover. Also level
of trust. Similar problem exists in Bluetooth networks. Seems to work.
How would this be different?

CB: interesting thing of BT networks that various products out there
need a manual step to actually setup initial security. Cases where that
is not case, discovery is really awful. Have to be really careful to not
send music to guy living upstairs. My systems discovers that and starts
sending.

MM: referring to BT connecting to my own devices and seeing neighbor
devices, but in general seems to work with devices in proximity. Works
for my stuff. Exposes my devices to other parties, but haven't
researched that.

CB: if BT has solved this, we should explain how they do it and how to
translate it here. Manual step is one aspect that would be different.

MT: I think it's an interesting topic. Biased by the RD model. Like
Milan said we should understand the scope better. Maybe start with
taxonomy of trust models for the early discovery phase. Kick-starting
that could be a first step.
CB: have any docs to point here?
MT: No, would be opportunity for me to understand the building blocks
better.

CB: deliberately presented as wide open but of course need to focus.
Good to have list discussion and a meeting.

Wrap-up

CB: expect to have further work meetings in the next months, with
cadence roughly of one month. If interested and have topics for such
meetings, talk to the chairs. Thank you!