[Ace] test planning?

Jim Schaad <ietf@augustcellars.com> Mon, 14 October 2019 01:47 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 E857612001A; Sun, 13 Oct 2019 18:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8DqtdREilIml; Sun, 13 Oct 2019 18:47:39 -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 A836F12006D; Sun, 13 Oct 2019 18:47:38 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 13 Oct 2019 18:47:32 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-ace-mqtt-tls-profile@ietf.org>
CC: <ace@ietf.org>
Date: Sun, 13 Oct 2019 18:47:29 -0700
Message-ID: <013d01d58231$5831ba40$08952ec0$@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: AdWBIa5YFyMZWJuuRUegEgOIDsi3LQ==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/0vys8RbBDLsm0mYh4eh78E_FtY0>
Subject: [Ace] test planning?
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, 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

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
	b.  Respond with an AUTH packet and re-run the POP via

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

1.  What requirements are there for validating the TLS client/server
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

I will still do a full review of the document.