Re: [Ace] test planning?

Cigdem Sengul <> Tue, 15 October 2019 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F3EE1200B3; Tue, 15 Oct 2019 02:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d10Q-Qnnbje5; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5B981200B2; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
Received: by with SMTP id u22so29571955qtq.13; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=meGLYsNXLWBliEqDU41OxnWxiDk7TdeK01QnKPDiMQs=; b=gl8W424ZbzVTcVraKZn+PxvZZJKxzZ1f6ecSHJdZ6jlQCbUOJJ68LM5nuVJTw1FeUD UkWrwkT9I8RP7No2bo9vJmHViPhiiT5vl2OTjnkRPK7fhU5nTOwvi5T7andMrHM+ojFD aA2JZzBBdfmCMUSn9pOL67m1QlAUIs1hlZRgXFN0wYp8QPGf32jR155zUy5BAwSBQ5Lp A9AFIKTGdsgj0Jc6enSUYuAJZY4TcI7rxETBv/iJLtfJEgMiUgBCng6shhlSoqs9FC6y up8kpAzlY06Km/9w/2rf4WE3atAbWpA8Mpr2p8wAPlbHmXVS3xVUQu/j5O72Pf65NL7X OhZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=meGLYsNXLWBliEqDU41OxnWxiDk7TdeK01QnKPDiMQs=; b=lUyXqhQst8LpNnxFsCH9eTAlhDpckoJ6j540JGpxvnBp8gOowhjviJyeOieKUor4co gvf8cTldvUxmbiE/Rrg/mVqYC0VyrYPLk1RGycWW88NJraTZMwUwRIBjADeItw8Krf11 asB71W2tKKt/qI7Wmjhez3edQhIUQLYtkrpg4Fyrv8DDhxUbgd68yfzyU6Wkk+yGurMT f4spBWF8fcGiXN4HqPgEtkUIvP5t45z3Obua1aGrpEWEPDYwT/JsNWEW+ki+xfUfRXmE HhNQRrclu3fbG+40Jqh4ah7X7Wv+l5lPTGVLXT1frOtvZ5K+ueLcOekHCsGwmiSmD74Q Z/kw==
X-Gm-Message-State: APjAAAUTVczdAB2q9d3YT8UMWUKVXp0o+heeMv5RcSlh1QfH7f30TrnN phRd0yBT8ICS9hxACYtIR+HpKXpSRj/Vm974G2adTmpZ
X-Google-Smtp-Source: APXvYqx+rrdGjMh8mGqhi//O3mOhrRB3a93xP5U6iUK+uk9ZczcSqX1YrG9Eq+WDCOqZhDOkuykUT6YKoyP0kTK7b/o=
X-Received: by 2002:ac8:1903:: with SMTP id t3mr38671620qtj.344.1571132212544; Tue, 15 Oct 2019 02:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <013d01d58231$5831ba40$08952ec0$>
In-Reply-To: <013d01d58231$5831ba40$08952ec0$>
From: Cigdem Sengul <>
Date: Tue, 15 Oct 2019 10:36:41 +0100
Message-ID: <>
To: Jim Schaad <>
Content-Type: multipart/alternative; boundary="0000000000006c881c0594efb903"
Archived-At: <>
Subject: Re: [Ace] test planning?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Oct 2019 09:36:56 -0000


Thank you, Jim, for this plan.
Responses are inline.

On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad <>; wrote:

> 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

Both options are supported but 1b is explained in the main document.
1a is explained as supporting an unprotected subscribe-only "authz-info"
topic in Appendix B.
We considered this as a MAY in section 2.1.2:  "To this end, the Broker MAY
support /authz-info
   endpoint via the "authz-info" topic.  Then, to transport the token,
Clients publish to "authz-info" topic unauthorized. "

Should this Appendix B come to the main document as some flows in section 2
require it? Should we explicitly say 1b is RECOMMENDED? Any opinions?

> 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.)

All except 2.e - we did not plan to support it.

> 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)

True for 3.b -> We need to clarify that the nonce needs to be part of the
data that is passed. Since we overload password/username for this, we may
to provide this in a structure in the username. Will define.

> 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.
4a. True - here post token to the server means start everything over with
CONNECT or "authz-info". If the client knows this is not due to token
expiration somewhat (hard to know in MQTT 3.1, then it may skip

> 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.

Do you mean apart from TLS certificate verification, whether the TLS client
checks server identity against a preconfigured reference identity?

> 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.

We added them as options with MAY statements.
How should we change the document to signal this more strongly?

> 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.
This is described in Appendix B - as a means of implementing "authz-info".
I think this suggests we should move authz-info to the main document.

> I will still do a full review of the document.
> Jim
Thanks for this. I hope I was able to clarify some of the issues.


> _______________________________________________
> Ace mailing list