[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
- [Ace] FW: WGLC comments on draft-ietf-ace-dtls-au… Jim Schaad
- Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtl… Olaf Bergmann
- [Ace] FW: [core] FW: WGLC comments on draft-ietf-… Jim Schaad
- Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtl… Göran Selander
- Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtl… Benjamin Kaduk
- Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtl… Jim Schaad
- Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtl… Benjamin Kaduk