* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ace Status Pages

Authentication and Authorization for Constrained Environments (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2014-Jun-16 —  

IETF-110 ace minutes

Session 2021-03-12 1700-1900: Room 6 - ace chatroom


minutes-110-ace-00 minutes

          **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)
          jabber: ace@jabber.ietf.org
          # Agenda
          Minute takers: Christian, Mohit.
          * Agenda bashing and [note
            * 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
            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.
          relation to [oauth](https://datatracker.ietf.org/wg/oauth/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:
          Please select
          Input type: kramdown
          Other: convert v2 to v3 XML
          v3 FAQ:
          (Details on what to do after converting to v3:
          xml2rfc mailing list:
          # 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:
          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
          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
          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
          ## 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
          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.

Generated from PyHt script /wg/ace/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -