Minutes IETF105: ace
minutes-105-ace-00

# ACE WG IETF 105, Thursday July 25, 2019 17:40-19:10 (1.5 hours)

Note takers: Christian, Jim Schaad

### Intro

Daniel Migault: presenting agenda

JS (Jim Schaad): Working group document review.
Turned over all of the documents and waiting for AD review from Ben
CB (Carsten Bormann): Priority indicated?
JS: PoP, EST, the four OAuth documents
CB: We really need PoP
JS: PoP is in AD's "I'm trying to review it" state

### Current Working Group Documents

* draft-ietf-ace-key-groupcomm, Francesca, 15min

Francesca presenting -02
https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-key-groupcomm-00
Recap of the mechanism.
Jim's review processed and signed off, going through changes.

CB: Have you considered RESTifying that? This is a set of verbs. In REST, we
usually do this over resources (create, delete, observe). FP (Francesca
Palombini): Haven't considered that. If you have suggestions on better terms...
. This is for new field (type), here we define what values mean. Can discuss
that.

Robin Wilton: When operation "leave" causes KDC to rekey, is there a
MAY/SHOULD/MUST tell the group members that rekeying is happening? FP: It's a
MUST. This document does not specify how rekey happens, Marco may tell more.
Robin: If KDC MUST update keys for a group, are the members told that rekey is
happening? FP: Depends on how rekeying is happening, depends on what is set up.
This draft is general. Marco Tiloca: Left to the application depending on
whether you need PFS.

Francesca continuing with right column of page 3
Open points with -02
Scope (p4), proposed solution (p5)

PvdS (Peter van der Stok): Technical detail to avoid confusion: Why not define
scope in the two documents, one for group membership and one for pubsub, and
leave it open in this draft? FP: Some things need to be specific to two
documents (values of roles, ...), but this can be the same in both. Format of
the scope can be same. Reason not to have same format? Daniel: So you want the
scope [defined] in two different places in [...]? FP: No just in one place
PvdS: Understand that scope is 2-array. But with several entries, it is used
differently[?], that's confusing. FP: Take this offline. I take this as "think
is confusing but not creating a problem"? PvdS: Implementer will take longer,
that's all.

Francesca continuing with open points (p6): nonce2, (requesting OAuth feedback
on) registering new parameters in AS creation hints (but where else?)

Mike Jones: Agree with Jim.

Francesca continuing on open points: format of keys

Further open points on rekeying (p7)

CB: This is the point where I need to repeat my RESTify request.
JS: One possible reason why this is better than REST here: Server can get
confirmation that client got it. CB: Can do that with observe too. You don't
get a response that the receiver liked it, but... FP: That's listed as one of
the options. CB: Alternatives are bad. FP: Profile needs to specify which
alternatives. CB: But why open a box of many alternatives? All need to be
implemented, interop-tested. [...] Until a profile comes along that really
needs this, why do it.

Francesca continuing on multicast message rekeying (last item on p7).
Will go ahead and implement this proposal.

Daniel: "implement"?
FP: Update the document.
Daniel: Curious about RESTification. What's the impact?
CB: Probably "some text changes"; can't answer in more detail before checking.

Francesca on difference to ace-key-groupcomm
(https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-coap-pubsub-profile-00
p2) ace-key-groupcomm provides for general group communication. pubsub-profile
is specific content for CoAP pubsub and COSE ace-key-groupcomm-oscore is
specific to CoAP groupcomm and OSCORE security

PvdS: (Like few minutes ago) Have to go back and forth, parse few lines at a
time. FP: First came here w/ CoAP pubsub profile in a single document. Then was
told "wait that's group communication, can reduce this". Then I did that. Then
was told to structured differently. Have to decide whether we want one document
with all profiles, or separate ones. Can improve for sure on duplicate and
repeating text, but need to decide a direction. I think this is the better
direction compared to a huge document where you jump from one section to the
other.

* draft-ietf-ace-groupcomm-oscore, Marco, 15 min

Presenting
https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-draft-ace-key-groupcomm-oscore-01
Updates after Jim's and Ludwig's review

Keep all three approaches?
Benjamin Kaduk: Surprised CB is not coming up with "choices are bad". CB
(getting up): choices are bad. CB: Haven't done work to decide which of these
we need, don't know answer yet but work should be done. FP as co-author: Think
it's good to have all of them and let application decide. CB: From the look of
it would guess it is, but let's do the work.

Marco continuing on p6

FP: Please say anything on your mind here, we need help on this.
CB: X.509 and RFC7250 RPKs are potential candidates. There should be a way to
register them once they're needed. Policy is probably more on the conservative
side... JS from floor: don't think registry is needed, should key confirmation
registry that's part of PoP document, that's there for all to use and can be
registered to as needed.

Marco continuing on p7, p8

JS "from the floor": should be a MUST. If not doing it, devices need to
retrieve all of the public keys from the KDC again? Marco: Happy to make it a
MUST.

Ludwig Seitz (via Jabber): why would the GM shuffle around Sender IDs?
Marco: If a single group member's sequence number wraps, GM can rekey the whole
group (big impact on performance) or to just assign new sender ID, and all can
resume. Other members derive a new security context, but on the wire it's
efficient.

Marco continuing on p9 on implementation, p10 on summary. Hope to go for full
interop in Singapore.

### Other Non-Working Group Documents

* draft-tiloca-ace-group-oscore-profile, Marco, 10min

Marco presenting
https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-draft-tiloca-ace-group-oscore-profile-01
about access control for resources at group members so far, any member can
perform any operation on any other member's resources  if a member of the group

PvdS ad p7: Every time you make a new group...? Possibly there is a subset
[...] it would be more stable. Marco: Yes, thanks.

Marco continuing to summary

JS from floor: Do we have real-world use case for this, or is that speculation?
Marco: Can come up with example
JS: That's speculation.
Marco: Unaware of real-world use case right now.

(off topic)

Ludwig (remote): For those not following side discussion on Jabber, there are a
number of ACE and CoRE documents dealing with communication security now. For
new participant, a wiki page or informational RFC that explains how those
documents interlink would be helpful. If someone volunteers, that helps.
Francesca has example in one draft
<https://ace-wg.github.io/ace-key-groupcomm-oscore/draft-ietf-ace-key-groupcomm-oscore.html#relation-to-other-documents>,
but having it in one document is not very helpful. FP: I volunteer.

* draft-palombini-ace-coap-pubsub-profile, Francesca, 15min

Francesca presenting
https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-coap-pubsub-profile-00

(p2) Case made, hoping to keep the current structure.
(p3) history / status update. CoRE pubsub is close to be done. MQTT pubsub
profile adopted in here. (p4) Current plans, posing questions to WG. on bullet
1. More general? Example?

JS: More general, no example. If you have an example, you have to document it,
and I think it's not worth it (registration and so on and so forth). FP:
Wouldn't be complicated to have as it's in current document. Daniel: Can we
understand the document w/o the example? FP: Yes.

Francesca continuing at bullet 2

Hannes Tschofenig: (FP proactively: You don't need OSCORE to do this). Who
provided the feedback for this? FP: Jim, and more reviews from earlier versions
Hannes: So multiple people suggested this? FP: Those come from the last review

Francesca continuing at bullet 3, and p5
Would like adoption soon so it can move forward together with MQTT pubsub, as
they are interested in protection of publication content.

Daniel: Who read? (1 hand)
Christian Amsüss: Latest or any?
Daniel: any? ca. 4 hands.
(Someone): And some more not in the room
Daniel: Would be good if MQTT people reviewed as well
FP: They have

### Any Other Business

* AOB, 20 min

JS: Had CoRAL side meeting this week. Need to define CoRAL vocabulary that can
be published with CoRAL document so people can locate things like
authentication, key servers and whatnot. Need to find people to do that. There
was a document in CoRE this morning that defines link format attributes that do
the same thing. Suggesting this should be migrated here as it's mostly focused
on advertising ACE features. Expect both things on the list next month or so.
JS: Ben, do you want to say you're reviewing documents? Ben: Had busy 2-3
months; only reviewed for ?, not for my working groups, things piled up. Things
have calmed down, cleared backlog, doing it FIFO. If reason to prioritize,
happy to move around. Right now in the middle of PoP, some more on ACE in next
couple weeks. JS: Before end of August? Ben: Yes