Re: [Ace] Planned updates to draft-ace-key-groupcomm

[Daniel Migault <[e-mail]>]

Thanks for the very details - please ship it! To the WG, please state your opinion by the end of August.

Yours,
Daniel

________________________________________
From: Ace <[e-mail]> on behalf of Marco Tiloca <marco.tiloca=[e-mail]>
Sent: Friday, July 29, 2022 12:20 PM
To: [e-mail]
Subject: [Ace] Planned updates to draft-ace-key-groupcomm

Hello ACE,

Following some discussions in the past months, I was planning to make
two non-invasive changes to draft-ace-key-groupcomm-15 [ACE-KG], which
is currently in AD Review.

After giving a heads-up to Daniel and Paul at IETF 114, this mail is to
check with the Working Group if there are objections to make the changes.

---

UPDATE 1

Following IETF 113, there was a proposal from Christian about updating
Section 7 "Extended Scope Format" of [ACE-KG]. The defined approach is
optional to use, it signals the semantics of a binary encoded "scope"
claim of an access token, and is referred to in the documents
[ACE-KGO][ACE-ADMIN].

The result of the change, also proposed in [GH-ISSUE], would be a
simpler and more efficient signaling of the scope semantics. In turn, it
automatically takes advantage of the work done in CBOR at [CBOR-FM].

Question: is there any objection to update Section 7 of [ACE-KG], based
on the proposal at [GH-ISSUE]?

---

UPDATE 2

At IETF 113, it was discussed that the "scope" claim of a same access
token could specify, at the same time, both: i) scope entries related to
roles of members in an OSCORE group, as per [ACE-KGO]; and ii) scope
entries related to admin permissions for Administrators of OSCORE groups
as per [ACE-ADMIN].

Following that discussion and in order to make things simpler, a single
AIF data model "AIF-OSCORE-GROUPCOMM" is now defined in Section 3 of
[ACE-KGO]. This still builds on the general requirements from Section
3.1 of [ACE-KG], and primarily serves what is specified in [ACE-KGO].

Then, the same AIF data model is extended in Section 3 of [ACE-ADMIN] to
serve what is specified therein. That is, in each Administrator scope
entry <Toid, Tperm>, Toid indicates a pattern of group names, while
Tperm indicates admin permissions on groups whose name matches the
pattern. In particular, Toid can be: i) the CBOR Simple Value "true"
used as wildcard, also part of a suggestion from Ben at IETF 113
[ACE-113]; ii) a CBOR text string specifying a literal group name; iii)
a tagged CBOR item specifying a complex pattern of group names, with the
CBOR tag indicating the pattern semantics (e.g., a regular expression
provided by a text string).

With the above background in mind, the small update for [ACE-KG] would
be in its Section 3.1, about having consistent general requirements when
using AIF. The requirements are currently mandating "Toid" to always be
a CBOR text string, while in fact "Toid" is only _often_ a CBOR text
string (also highlighted by Ben at IETF 113 [ACE-113]). The change can
simply mandate the use of exactly a CBOR text string only for scope
entries related to group members, i.e.:

OLD:
If the AIF format is used, each scope entry is encoded as specified in
[I-D.ietf-ace-aif]. The object identifier "Toid" corresponds to the
group name and MUST be encoded as a CBOR text string. The permission set
"Tperm" indicates the roles that the Client wishes to take in the group.

NEW:
If the AIF format is used, each scope entry is encoded as per
[I-D.ietf-ace-aif], according to the used AIF specific data model. If a
scope entry expresses a set of roles to take in a group as per this
document, the object identifier "Toid" specifies the group name and MUST
be encoded as a CBOR text string, while the permission set "Tperm"
specifies the roles that the Client wishes to take in the group.

Question: is there any objection to update Section 3.1 of [ACE-KG] as above?

---

Reminder: there are also some minor, editorial changes that are pending,
as already mentioned at point 1 of [MAIL] and during the IETF 113
presentation of [KGO]. These updates are about consistently aligning
terminology and parameter names, as triggered by the WGLC review of
[ACE-KGO] at [REVIEW] and by the latest updates to the CoRE document
[GROUP-OSCORE].

I can certainly process these small pending changes together with the
two main ones above.


Thanks,
/Marco


[ACE-KG]
https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-15

[ACE-KGO]
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/

[ACE-ADMIN] https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/

[GH-ISSUE] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a993cf57d4eb0424&q=1&e=f7c78eb1-ef42-4a78-b159-4fd24b9b965e&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm%2Fissues%2F144

[CBOR-FM] https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/

[ACE-113] https://notes.ietf.org/notes-ietf-113-ace?both

[MAIL]
https://mailarchive.ietf.org/arch/msg/ace/wBpceZW1qT1YYICzECnKqvdwQb8/

[REVIEW]
https://mailarchive.ietf.org/arch/msg/ace/SIB_rte0orqkvDEtTAw-1F7Cdzo/

[GROUP-OSCORE]
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/

--
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3d296ae5721cac2b&q=1&e=f7c78eb1-ef42-4a78-b159-4fd24b9b965e&u=https%3A%2F%2Fwww.ri.se%2F