Minutes IETF110: ace
minutes-110-ace-00

---
**Authentication and Authorization for Constrained Environments (ace)**

IETF 110 - 2021-03-12 16:00-18:00 Friday Session III

---

Daniel Migault (ericsson)
Loganaden Velvindron (cyberstorm.mu)

\[~~etherpad~~ codimd](https://codimd.ietf.org/notes-ietf-110-ace)
\[meetecho](https://gce.conf.meetecho.com/conference/?group=ace)
\[material](https://datatracker.ietf.org/meeting/110/session/ace)
jabber: ace@jabber.ietf.org

---

# Agenda

Minute takers: Christian, Mohit.

* Agenda bashing and [note
well](https://docs.google.com/presentation/d/1YuUzfZMbMijvpJJkBoOkppOaec4u2S_TMBowo1EqQVY/edit?usp=sharing)
  * blue sheets, jabber scribe, new co-chair presentation

  Daniel introducing Logan

* WG status
* Working Presentation
  * draft-ietf-ace-cmpv2-coap-transport 15 min
  * draft-ietf-ace-wg-coap-eap  15 min
  * draft-ietf-ace-aif Carsten 10 min
  * draft-ietf-ace-key-groupcomm Marco 15 min
  * draft-ietf-ace-key-groupcomm-oscore Marco 10 min
  * draft-ietf-ace-pubsub-profile Cigdem 5 min
  * draft-ietf-ace-oscore-gm-admin Marco 10 min
  * draft-tiloca-ace-revoked-token-notification-04  Marco 10 minutes)
  * draft-tiloca-ace-group-oscore-profile-05 Marco 10 min

# WG status

Daniel going through the document.

* Publication queue
  * draft-ietf-ace-coap-est

    waiting for a reference (DTLS)

* sent to the IESG telechat:
  * draft-ietf-ace-oauth-authz
  * draft-ietf-ace-oauth-params
  * draft-ietf-ace-oscore-profile
  * draft-ietf-ace-dtls-authorize

* AD review
  * draft-ietf-ace-mqtt-tls-profile

    How aligned is this with updated framework text? (Not about changes, more
    about recommendations between C-AS and C-RS). CS: Not a problem.

* WGLC
  * draft-ietf-ace-aif

  CB: Thanks Christian for the review (yesterday); not looked at yet. This is a
  6w WGLC, my personal record. Still ample opportunity to provide reviews. DM:
  LV to be shepherd.

* New adopted drafts:
  * draft-ietf-ace-cmpv2-coap-transport
  * draft-ietf-ace-wg-coap-eap

* WG focus
  * draft-ietf-ace-key-groupcomm
  * draft-ietf-ace-key-groupcomm-oscore
  * draft-ietf-ace-cmpv2-coap-transport
  * draft-ietf-ace-wg-coap-eap
  * draft-ietf-ace-pubsub-profile

[current milestones](https://datatracker.ietf.org/wg/ace/about/)

DM: Not going in here, we're good.

[interim
meetings](https://ietf.webex.com/ietf/j.php?MTID=m4d4b02389fc6f862663a7ac103a9d9ce)

relation to [oauth](https://datatracker.ietf.org/wg/oauth/documents/) /
[gnap](https://datatracker.ietf.org/wg/gnap/documents/)

DM: I want to make sure that we're not evolving on our own, we keep in touch
with those. Who's attending them? (collecting +1 in chats). Collected: +1 on
gnap (Olaf Bergmann)

# Note on XMLv3 submission

## kdrfc

gem install kramdown-rfc2629
pip3 install xml2rfc

kdrfc -3chi draft-x.md

You get:

— draft-x.txt
- draft-x.html
- draft-x.v2v3.xml

…and an idnits report.

Submit the draft-x.v2v3.xml at https://datatracker.ietf.org/submit/
(Do NOT submit the .txt at the same time — that will be regenerated.)

## online tools

To convert a markdown file (specifically kramdown) to v3 XML, you can use the
converter available here: https://xml2rfc.tools.ietf.org/experimental.html

Please select
Input type: kramdown
Other: convert v2 to v3 XML

v3 FAQ:
https://xml2rfc.tools.ietf.org/xml2rfc-doc.html
(Details on what to do after converting to v3:
https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-after-converting-an-xml-fil)

xml2rfc mailing list:
https://www.ietf.org/mailman/listinfo/xml2rfc

# Presentations

## CMP over CoAP

Mohit presenting (see slides)

CMP over CoAP already done, this sets guidelines.

Please read and comment.  A list of key topics is in the slides.

DM: Any concerns especially w/rt the proxy?
CB: When you use proxies with DTLS, then the proxy is in a position to
influence the data (middleperson attack). Is this discussed? MS: Certificate of
proxy should be trusted by the IoT device. RAs (or whatever is closest to an
RA) can act as a proxy also. CB: So proxy needs to be in same security domain
as the end server. MS: Also case for UDP sendable to everyone. RAs can mitigate
and block things that are not known. (chat): "SHOULD be configured to trust the
[...] proxy". Do we have concerns with that? CB: Trust has to be in the device
as well. Having a signed certificate from some CA I trust does not mean the
proxy itself is trustworthy. MS: Idea is that the proxy should be at the edge
of the network where all the IoT devices are; before they go to the Internet
the proxy can be at the GW and managed by the ... two types, either by the
CA/RA[?] so devices trust it. Other case is someone has that proxy at the edge.
At that point, the proxy can convert CoAPS to HTTP, and that would be managed
by same admin who is running them devices. CB: It's not about trusting
certificates, I trust many certificates but not the websites behind them. Not
sure, maye CMPv2 doesn't need that (but then it doesn't need DTLS either). BK:
Carsten, I don't know if you are aware that CMP has a dedicated
extendedKeyUsage value in the certificate for the RA.  So if you trust the root
CA, you can trust that the entity that holds the private key of that
certificate is supposed to be acting as an RA. MS: DTLS is only required for
privacy, not for trust.

## CoAP EAP

DGC presenting (see slides)

p3: Bootstrapping service. Server chooses authentication method.
p4: After EAP success, IoT device has joined the security domain and
established a registration. Controller and device now share key material.

CA: The usual thing to do with CoAP here is to make recommendations about ways
to use CoAP, but not assume you have control, and especially not require peers
to do that. DGC: We should go with an assumption that we cannot make
requirements on the CoAP layer

MSethi (via jabber): can we not have bullets in abstract? the iana section is
incorrect. It should request IANA to assign a value for CoAP as a lower layer
in the EAP registry:
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-lower-layers.
I have not read the latest version of the draft but plan to send my review in
the near (or far) future. would be good to investigate if some optimizations
can be achieved by tighter integration between coap and eap. for example
relationship between coap message-id and eap request/response-id08 DGC: Will
need some research there; can use message ID if we have control over it. DM:
Which is the protocol to be left unchanged, CoAP or EAP? DGC: CoAP should not
be changed, should be able to use numbers in CoAP to send to EAP state machine.
Try to avoid EAP state machine as much as possible. If on CoAP side we can
create the state to feed to EAP, that would be good. MS / [?]: Guess neither of
the implementations can be changed; unclear: implementation meaning state
machine or DGC: That's why asked about control over CoAP engine. [?] Look at
how much we can achieve. Worth exploring. CB: Reason to use CoAP is that it's
implemented; demands not met by imlpementations don't get wins. What you can do
is use properties of CoAP. Eg. you know there can be duplicate message
detection. You can use the properties rather than influencing the header
fields. DGC: So look at inherent characteristics without further demands. Build
things by assuming we get standard CoAP. Raphael ML: Using sequence numbers is
because we need to keep sequence of [?]. We abstract the application from the
implementation. If you check the flow, then you wait for a particular sequence
number. Also thought: If we can get rid of sequence numbers eg. using mix of
message ID or token ... that's the main question. If we can from an application
part say to the CoAP engine to set this ID, can we get rid of the sequence
number? Just in case, we have it included.

BK: The EAP state machine is sensitive. Slight modifications can cause security
problems. (Came close to publishing a document w/ broken state machine). DGC:
That's why I'd like to keep it out of the modifications. RML: No need to change
EAP state machine. EAP standard is clear about requirements to lower layer.
Wouldn't go for optimizations at state machine side. What it requires from
lower layer is sequence numbering. DM: There's CoAP and EAP layer, we don't
want to change them much. There could be a compression layer inbetween that
could take some parameters from one and expand those to EAP, so that when the
uncompressed packet hits EAP, it's not changed. DGC: That's the idea. If we can
map the message ID in and make sure it does not cause alterations, that'd be
the idea. DM: Looking at compression, there's SCHC, are you aware of that? DGC:
[...] try CoAP-EAP on LPWAN networks. [...] take EAP even further. DM: So we
can also split it (compression), not everything needs to be in same document.

## Pub-Sub

CS presenting (see slides, with discussion points)

DM: I hear no disagreement; any strong agreement?
DM: So we'll wait for the next version with the simpler architecture.
CS: So I'll move to next new version then?
DM: Yes. Comments please also to the list, as it's a significant deviation from
the current draft. DM: On second issue (group join request) -- unsure, any
thoughts from groupcomm folks? CS: It's more an issue of whether I have the
right tools to work around it. First issue is that topic filters might suggest
multiple groups where client is not aware of which groups they correspond to.
So it's about multiple groups joined in a single filter. Not sure how this
works for CoAP. In MQTT, there's wild cards. If they are grouped differently at
KDC, different resources get different keys, but client isn't aware of that. BK
on Jabber: on security of topics only guarded by broker CS: Yes ... depends on
how groups are managed [?]. Can solve this at application layer. Like, if there
is a clear application requirement to get an exact membership.[?]. Can clarify
that, it's just that it's a little bit more strict than we do in MQTT TLS
profile. Marco Tiloca: Does this require any adaptation in ace-key-groupcomm?
CS: Trying to avoid that by using existing APIs provided by groupcomm. Just
trying to figure the best way to addres this -- either being too strict at
application and making clients request exact groups, or when being flexible,
how to provide that. MT: key-groupcomm-oscore works in an easier way, but you
join precisely the security group. The coupling you talk about is, for us in
CoRE, by defining separate security and application groups that may have up to
many-to-many mappings. Approach could be useful here if you think of
application groups as your topics. CS: Looks promising. one-to-many...? MT: You
can use many security groups with a single application (simple and safe), ...
other direction trickier but have to be careful (documented). CS: Promising.
MT: See application groups and security groups in
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/

## Summarizing WG documents

DM: CMPv2 is close to be ready, looking at interim. For others, more updates?
Continue progress discussion in interims.

## key-groupcomm

MT presenting (see slides)

MT: Btw, pubsub of before is an application profile of this.
p5: MT: Need feedback, if I am not missing any combination in slide 5
DM: Look at this with a pen; MT: comments can also come in an advanced review.

BK on p6: need time to ponder on whether kid=node ID can hold.
BK: Part of why it's hard for me to be certain is that COSE is more a framework
and less of a protocol. There's little guarantee on what goes kid. Maybe we
can, as an application, assert what goes in kid, but I'm not sure. MT: Can be
left to application profiles. Node identifiers are assigned by the KDC, e.g.
the Group Manager of Group OSCORE. DM: Do we conclude over that? MT: The new
'peer_identifiers' parameter is an additional optional parameter to be use in
future cases.

DM on p7: Ensure we're not squatting code points.
MT: It's a new registry.

CS on p9: Also matters to pub-sub. Use AIF there too in scope. Nice to see
generic way. MT: The AS should be strongly recommended to use this unless
there's just one application known to run on the KDC for which the Token is
issued.

CB: Who are we envisioning to actually register something there? Should an
application register semantics? MT: ace-key-groupcomm-oscore is registering an
integer. CB: So it's specification-required with small number of specs? Or will
specific applications go ahead and do something? MT: Intended to be pretty open
for any possible application, not only profiles of this document. Tricky to
handle is squatting of semantics, don't want two codes to be used for one
purpose and then one switching to the first.

BK: Actual specific is key part here. Are there any cases where you want this
usable without the explicit tag? MT: That means you need to know in advance it
is extended scope format. Can't think of any, can't exclude. It'd save the tag,
but harder to manage.

CA: if there's a risk of colliding with something else, then there's already
risk of colliding with other binary types.  If there is a risk, the tag is just
reducing the risk that a random data sent by some other application is
misinterpreted MT: Tag just tells you to parse this as a sequence of two
elements. CA: if there is any danger of the other party (AS/RS) not having
this, then the other party might still be using some other format? MT: Also
related to Ben's. It works if you already know in advance it's always, or is
never extended format.

MT: Can close the issue based on this.
DM: Had much discussion on those.

DM on WGLC question: Presentation shows latest version?
MT: Yes, the issue on the last point just left open in case there was something
coming up today. DM: Think we can start WGLC next week. Expected
ace-key-groupcomm-oscore and this to be sent together ... but that's next
presentation. MT: Can imagine shipping them together; in WG lifetime there may
be a bit of a shift.

## draft-ietf-ace-key-groupcomm-oscore

MT presenting (see slides)

MT on p5: to remove reduntant parameters, as already done in equivalent data
structures of core-oscore-groupcomm; this is specific to this document, no
changes needed in ace-key-groupcomm.

DM on p5: Good to remove redundancies, move ahead

MT: More updates planned to synch with ace-key-groupcomm (following its WGLC
updates) and done/upcoming updates to core-oscore-groupcomm. So probably not
ready for WGLC yet.

## Closing Statement
DM: Don't have time to other presentations. have lot of work to do in next
interim meeting. And glad to see all the work.