[Ace] draft-ietf-ace-key-groupcomm

Jim Schaad <ietf@augustcellars.com> Wed, 03 April 2019 01:00 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 38CB91203FB; Tue, 2 Apr 2019 18:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.794
X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SM-Kaft8aFMG; Tue, 2 Apr 2019 18:00:13 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFEF1203EF; Tue, 2 Apr 2019 18:00:12 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Apr 2019 18:00:05 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-ace-key-groupcomm@ietf.org>
CC: <ace@ietf.org>
Date: Tue, 2 Apr 2019 18:00:02 -0700
Message-ID: <027e01d4e9b8$93397ea0$b9ac7be0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdTog2+RRDEhSuKnQTeDAzz1P2GXjw==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/b5-INK5DZma1Qc-F3PUAMKmZe6o>
Subject: [Ace] draft-ietf-ace-key-groupcomm
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 01:00:15 -0000

I read this document on the flight back with the idea of thinking about
doing an implementation.  In the process I found that it does not seem to be
ready to start on an implementation.

1.  This document is written explicitly in terms of using CBOR as the
encoding format.  Should it be written such that either JSON or CBOR can be
used for the underlying encoding?  While I personally don't care, it may be
that either Hannes or the MQTT authors might find this to be something that
would be useful.

2.  Is there a content type that is planned for the messages used in this
document?  If the plan was to use application/ace+cbor then this both needs
to be stated and should be cleared with the group in general.  If there is
no plan to create one then it would be useful to state this.

3.  The document does not have a table which deals with abbreviations, does
this mean that the full text string is what is going to be the key?
Depending on the content type being considered, these values could be
assigned (new registry) or marked as TBD, but if this is supposed to happen
then it needs to be placed in the document.

4.  Should the references to RFC 7390 be replaced with the new document
being considered for the CoRE working group?

5.   Section 2 - In the last paragraph - should the word "further" be
omitted as there did not seem to be any previous communications discussed.

6.  Section 3.1 - Is there a reason why one cannot request access from the
AS for multiple groups/topics in the same request to the AS? 'scope'

7.  Section 3.1 - Is there a definition of the values for "role" that can be
requested.  What is the type of this field for a single value, or for
elements of the array?  Is there a default if role is omitted on the

8.  Section 3.2 - IN the last paragraph did you mean to say that a new token
would be returned or that the existing token can be returned.

9.  Section 4.1 - If the 'client_cred' field in a request is filled in, and
it is not the same as the public key used to establish the TLS session
between the client and the KDC, what is the procedure to do a POP on this

10.  Section 4.1 - What is the data structure for client_cred?

11. Section 4.1 - For 'pub_keys_repos' what is the format of this field?

12. Section 4.2 - I am not completely sure that I understand what
verification checking means in the first paragraph.

13. Section 4.2 - What is the profile that I am checking for the 'kty'
field?  Was I supposed to have a chance to request a profile someplace?

14. Section 4.2 - Put the fact that the 'key' field is profile dependent on
the 'kty' in the 'key' paragraph.  Is it legal to define a 'kty' which does
not have a 'key' field?  If so then should this field be defined by the
profile?  Ok, I just read the full next paragraph and now I am just

15. Section 4.2 - What is the type of profile?

16. Section 4.2 - Is exp supposed to be a UNIX time - if so then it should
say so.  Might be easier to reference this as CBOR Tag 1 w/o the tag.

17.  Section 4.2 - 'pub_keys  "In case public keys are represented as
COSE_KEYS"  Does this mean that other items are legal - if so then how am I
supposed to know this.

18.  Section 4.2 - What is the type of 'group_policies'?

19.  Section 4.2 - What is the type of 'mgt_key_material'?

20.  Section 4.2 - The last paragraph seems to be something of a
non-sequitur.   Perhaps this is better omitted and just put someplace else,
like the next section.

21. Section 5 - Is there some type of requirement for positive delivery of
new keys in the event of a KDC changing the key.  I put this here wrt a node
leaving, but it applies equally to a node getting itself added.

22.  Section 5.1 - There currently is no way for an AS to communicate to the
KDC that an authorization has been revoked.  There is only a way for a KDC
to ask the AS by introspection.  The first sentence is problematic.  Do we
need some type of extension to support this?

23.  Section 5.2 - If a topic is provided and the user is authorized for two
topics which use the same group, what happens if the user asks to leave one
of those two topics but wants to say on the other?  

24.  Section 5.2 - What is the purpose of providing the 'client_cred' in a
leave request.  It makes more sense to provide the id in the group than this

25. Section 5.2 -  It is not clear to me that the correct answer to a badly
formatted leave request is to send a bad request error back.  I would think
that as long as the KDC can figure out what is being referred to then the
sender should be removed from the group.

26. Section 5.2 - It is not clear to me if the last paragraph means that the
KDC can remove the AS access token from it's database when a leave occurs,
or if it can only be removed when it expires.

27.  Section 6 - If the 'exp' parameter is not specified, when does keying
material expire?  This is not covered in the first paragraph.

28.  Section 6 - in the second paragraph it says that the problem is not
being able to decrypt a message, the correct condition is not being able to
find key material.  A corruption in the message should not require the
entity to looking for a rekey event to be checked.  This is a bad DOS vector

29. Section 6 - Should a KDC employ a best effort to keep the same kid value
when a group is rekeyed so that one could check the signature even if the
key material has moved on as this would provide a potential DOS attack to be

30.  Section 6 - should a client keep a the decryption failures so that they
can be decrypted after getting new key material or is this to be treated as
a loss of message?

31.  Section 6 - How does the event of sending the re-key material as a
multicast message in general lock out the entity that just left the group?
This should be discussed.

32.  Section 6 - There needs to be a method for a client to say that it
needs a new key id someplace in the protocol which may or may not cause a
new re-key operation in the event that it sends too many messages on the
current content. 

33.  Section 6.1 - What happens if I ask for a key re-distribution, but
supply a different scope than for the original message < assumes a
multi-topic scope>.  I am not sure what the purpose of the scope is at this
time given that you are not checking roles as well.

34.  OUT OF ORDER - Should a KDC have a single resource which allows for it
to return a group based on what the topic/scope is that is passed in without
the client first knowing what the group id is going to be?

35.  OUT OF ORDER - are all of the resource names required to be at the
root?  If I have a KDC which is shared with something else (say a Pub Sub
server) then it would make sense to have post to /KDC/group-id.

36.  Section 7.1 - what is the format of get_pub_keys when group member ids
are included?

37.  Section 7.2 - There is a race condition caused by the last paragraph in
this section.  Entity A sends a message, leaves the group, Entity B receives
the message and askes for the public key.  Is this an issue?

38. Section 91. - can the profile column have multiple values?

39.  It would be useful to have a section which describes all of the items
that a profile must cover in order to be used.