[Ace] Comments on draft-ietf-ace-key-groupcomm-02

Jim Schaad <ietf@augustcellars.com> Fri, 12 July 2019 16:52 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-ace-key-groupcomm@ietf.org
CC: ace@ietf.org
Date: Fri, 12 Jul 2019 09:51:55 -0700
Message-ID: <006501d538d2$1e344f90$5a9ceeb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Thread-Index: AdU3eNA6c9mofJxHSGiD+iIXzRM8LQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/6yqJzQm4u-MZYifhzyKhz5BAerQ>
Subject: [Ace] Comments on draft-ietf-ace-key-groupcomm-02
Precedence: list

1.  Figure 2 is a bit odd in that the marker for the ACE framework appears
to be attached to the Dispatcher and not to the set of messages w/ the AS
and KDC.  One of the things you might want to consider is to move to the V3
xml2rfc language where you can do this is SVG and get a cleaner picture.
(Although this requires some changes on the datatracker and I am not sure
how fast they are coming in.)

2.  Section 3 - I am not sure that the last line of the second paragraph
matches what you are doing in this document.  I would expect that there is
either no content type of ace+cbor as a general rule.

3. Section 3.1 - I already noted this but I think you need to be able to
specify multiple elements in the scope.  Look at the scope definition in the
MQTT draft.  Additionally - is the default common to implement one or the
only one?

4. Section 3.3 - Is there going to be a method to get these values if I post
the token as part of a symmetric DTLS connection to the KDC?

5.  Section 4.1 - I don't like signing just the nonce from the KDC for
client_cred_verify - never sign something that you are not supplying some
data for or you have an oracle.

6.  Section 4.2 - I am wondering if you considered using 'cnf' to in all of
the places where you are passing keys around?

7.  Section 6 - The end of the first paragraph is confusing me.  I don't
understand the conditions and actions that are being documented here.

8.  I am trying to understand what the structure that this is placing on the
KDC is, at least in concept.   If you start with

KDC has resources
	/post tokens here
	/group id 1
	/group id 2
	...
	/group id n 
 
So far I have no problems with this.  You next apparently have the
conceptual structure of
	/group id x
		/scope 1
		/scope 2
		/scope 3

Now the problem I have with this is that all of these scopes are going to
have the same group id and thus will have the same group keying context.  If
this is the case, then I am not sure that I fully understand why having
multiple scopes makes any sense.  

Jim

[Ace] Comments on draft-ietf-ace-key-groupcomm-02 Jim Schaad