[Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize

Jim Schaad <ietf@augustcellars.com> Mon, 22 October 2018 19:36 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9B8130E94 for <ace@ietfa.amsl.com>; Mon, 22 Oct 2018 12:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g1qURWV9dH6 for <ace@ietfa.amsl.com>; Mon, 22 Oct 2018 12:36:00 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FD4130EAB for <ace@ietf.org>; Mon, 22 Oct 2018 12:35:59 -0700 (PDT)
Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:31:11 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: ace@ietf.org
References:
In-Reply-To:
Date: Mon, 22 Oct 2018 12:35:52 -0700
Message-ID: <029e01d46a3e$72bad330$58307990$@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: AdRnTEAL0JSHf2QBS9irbfSoo+ynjwC8isgg
Content-Language: en-us
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/BBsCkkdDhlk-jqCHoljIav-S64Y>
Subject: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize
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: Mon, 22 Oct 2018 19:36:11 -0000

This was cc-ed to the wrong list

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com> 
Sent: Monday, October 22, 2018 12:09 PM
To: 'draft-ietf-ace-dtls-authorize@ietf.org'
<draft-ietf-ace-dtls-authorize@ietf.org>
Cc: 'core@ietf.org' <core@ietf.org>
Subject: WGLC comments on draft-ietf-ace-dtls-authorize 

Section 3 - Am I just missing where you talk about introspection or is it
missing from the text?

Section 3.2 - looks like you missed a "cnf" in the first paragraph - should
be req_cnf

Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level?

Section 3.3 - I am always bothered by the fact that PSK should really be PSS
at this point.  The secret value is no longer a key and thus does not
necessarily have a length.  There is also a problem of trying to decide what
the length of this value would be based on the algorithm.  If the client
offers TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_AES_256_CCM_8  (I may
have gotten these wrong but the intent should be understandable) then what
length is the PSK supposed to be?

Section 3.3 - Figure 5 - Is this defining a new set of entries for cnf or is
there a missing layer someplace?

Section 3.3 - Should some type of key identifier also be defined so that the
entire token is not always sent on every DTLS setup?  Also so that the key
can be referenced on a second request to the AS.

Section 3.4 - Is it worth while to make it explicit when the DTLS session is
required to be shutdown and that a simple authorization error is not one of
them?   Looks like it should be - these errors SHOULD NOT cause the DTLS
connection to be closed.

Section 4 - The requirement that the "kid" be in a previously issued token
would have problems with this if you were to use the "kid" of an RPK which
can be constant rather than being changed on each newly created token.

Section 4 - The term "must associate" is slightly ambiguous - does this mean
add to (augment) or replace the previous token.

Section 4 - Should a secondary access token have a later expiration date
that the one that contains the actual key value?

Section 5 - this seems to be a very strange place to define the new
parameter.

Section 8 - you need to put your kid in the IANA considerations as well

Section 9.1 - Having tilicoa-tls-dos-handshake as a normative reference may
cause problems unless this is on a publication track.

Section 9.3 - Can we get these URLs converted over to normal references?  


Jim