[Ace] test planning?
Jim Schaad <firstname.lastname@example.org> Mon, 14 October 2019 01:47 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E857612001A; Sun, 13 Oct 2019 18:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DqtdREilIml; Sun, 13 Oct 2019 18:47:39 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [18.104.22.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836F12006D; Sun, 13 Oct 2019 18:47:38 -0700 (PDT)
Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 13 Oct 2019 18:47:32 -0700
From: Jim Schaad <email@example.com>
Date: Sun, 13 Oct 2019 18:47:29 -0700
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Microsoft Outlook 16.0
Subject: [Ace] test planning?
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 01:47:41 -0000
I was going through the document and trying to figure out what a test plan might look like. I was also trying to make sure I understood all of the information flows. 1. Post the token to the server before starting: a. Yes b. No 2. Establish the connection to the server: a. Use the token as the PSK ID b. Use the token ID (or key ID) as the PSK ID (Requires 1.a) c. Use RPK for server & client authentication (Requires 1.a) d. Use RPK for the server but anonymous client (Could be X.509 cert for the server) e. Anonymous for both client and server authentication (Does not seem to be usable as none of the methods in 3 provide for server authentication.) 3. Send MQTT Connect message a. Use underlying TLS session for authentication - No additional POP is required on the CONNECT event. Permissions are inferred from the token used for client authentication to TLS (2.a, 2.b, 2.c). (Works with all versions of MQTT.) b. Use POP as a password over client ID + nonce. (Not clear where the nonce is carried for MQTT 3.1.1) This replaces the TLS client authentication (2.d). Requires use of JWT as binary not allowed. c. Use the POP via challenge/response. Replaces the TLS client authentication (2.d). (Requires MQTT 5.x) 4. Update token within an open session. If the server closes the session or sends a DISCONNECT then this is moot. a. Post token to the server. (Only thing that would work for MQTT 3.1.1) b. Respond with an AUTH packet and re-run the POP via challenge/response. 5. Update token after a session is closed. Start with step 1 above and create a new session. Based on this, there are a couple of things that need to be clarified in the document: 1. What requirements are there for validating the TLS client/server identities. 2. Is the option in 3.a planned to be a legal option or not? If so then it needs to be documented as such. 3. Does it make any sense to allow for the publication of a new token to the server via a publish to a fixed name. One would not allow for it to be subscribed to. This would allow for an authenticated post rather than the unauthenticated post and would also allow an update method for option 3.a. If not, doe the option of 4.a make sense and should it be documented as such. I will still do a full review of the document. Jim