Minutes interim-2021-ace-02: Thu 10:00
Authentication and Authorization for Constrained Environments
||Minutes interim-2021-ace-02: Thu 10:00
ACE interim meetin of 2021-02-11
agenda bashing ( 5 min )
* jabber scribe: Marco
* minute taker: Rikard
* WG status
## WG status
* New co-chair
DM: Close to having a new chair. Ben will announce it on the mailing list.
DM: The current timeslot collides with the IESG telechat, so the timeslot will
be changed. I will check on the mailing list that it is fine. MT: Please avoid
this time on Wednesday, we are planning to move CoRE interims to Wednesday.
DM: What about Tuesdays at 16 (CET)? I will try to find a slot on Tuesdays.
* Charter is ongoing
DM: Expect charter will be approved next week. This can ease adoption of the 2
drafts to be discussed for adoption today.
* Call for adoption for:
* Words smithing
DM: We want to make sure a constrained device using for instance OSCORE does
not have to implement TLS. So there is a strong recommendation the AS
implements a protocol from a profile. OB: We need to say something about
C<->AS communication. The profiles may say what security transport to
use. There is a recursion in the Profile-Framework references. CB: Too
restrictive to say for instance DTLS must be used C<->AS and
C<->RS. The protocols can be different. DM: Should the framework limit
requirements from the profile to security requirements? DM: The 2 profiles
should have same text, and it should be clear multiple protocols can be used
but one prefered. DR: Working on BACnet profile. It is odd that C<->AS
communication is not mandate. It should not be left unspecified. CB: The
frameworks should not overly constrain the profiles. DM: To sum up; we should
not specify one protocol into the profile. Since that can be defined in your
(BACnet) framework? DR: Yes. SG: We should recommend a protocol but allow to
use something else if it meets the requirements.
DM: Text from OSCORE profile is good, the one proposed by Olaf is similar.
Should be recommendations but leave space for other protocols. Framework should
say that requirements must be met but possibly by use of different protocols.
Profiles must recommend one.
OB: Problem by the profile recommending one may be for constrained devices,
mandating them to implement multiple protocols.
DR: A profile must provide (specify) at least one way, not leaving it
completely open. CB: We can all agree on must specify. DM: So a recommend or
should rather than a must. Let us continue discussion and try to agree this
* Ongoing Work:
* [draft-ietf-ace-aif](https://tools.ietf.org/html/draft-ietf-ace-aif-00) (
WGLC ready ? )
CB: Discussed and got good reviews from Jim and Francesca. Has now been
resubmitted with TBDs filled. Also added security considerations, feedback is
welcome from reviewers. We can go into WGLC for me. DM: I will look at it and
probably start WGLC. We need reviewers by next week.
* Volunteers to review ?
CA: I will have another look. (Christian Amsüss)
MT: Not sure for next week, but I will review. (Marco Tiloca)
OB: I can also, within last call. (Olaf Bergman)
( WGLC ready ? )
MT: Worked on points from last interim.
MT: An extended scope format is one open point. How does KDC understand
semantics of scope? A hint can be given using a CBOR tag combined with a
following integer. CBOR Sequence: [semantics, scope]. Only 1 CBOR tag value
needs to be registered. This solution has been added to editors copy. MT: Is
this best place to do this (it is general), or shall a separate document be
created for it? DM: I would prefer not having a separate document. CB: I agree,
it can be defined here if separated editorially. MT: I will make the text more
CA: How does using the audience fall short?
MT: It works but requires synchronized pre-agreement. A proper format with a
registry seems more stable and maintainable.
CB: Is domain of scope and domain of audience coupled strongly? Requires
DR: Why is this deep into the scope, not earlier demultiplexing at the
authz-info? MT: Audience can be used for that. DR: For us audience equals RS,
or group of RSs. DM: This can be brought to the next meeting, or continue on
DM: Some questions remain to make the document move forward. I will reach out
1. Daniel Migault
2. Marco Tiloca, RISE
3. Olaf Bergmann, TZI
4. Rikard Höglund, RISE
5. Christian Amsüss
6. Dan Garcia
7. Carsten Bormann, TZI
8. Dave Robin
9. Michael Richardson, Sandelman Software Works
10. Mohit Sahni
11. Rafa Marin-Lopez
13. Stefanie Gerdes
14. Peter Yee, AKAYLA