Re: [Ace] test planning?
Cigdem Sengul <email@example.com> Tue, 15 October 2019 09:36 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3EE1200B3; Tue, 15 Oct 2019 02:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d10Q-Qnnbje5; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B981200B2; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id u22so29571955qtq.13; Tue, 15 Oct 2019 02:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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-Received: by 2002:ac8:1903:: with SMTP id t3mr38671620qtj.344.1571132212544; Tue, 15 Oct 2019 02:36:52 -0700 (PDT)
From: Cigdem Sengul <firstname.lastname@example.org>
Date: Tue, 15 Oct 2019 10:36:41 +0100
To: Jim Schaad <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Content-Type: multipart/alternative; boundary="0000000000006c881c0594efb903"
Subject: Re: [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: Tue, 15 Oct 2019 09:36:56 -0000
Hello, Thank you, Jim, for this plan. Responses are inline. On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad <firstname.lastname@example.org> 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 need 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 authz-info). > 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. Sincerely, --Cigdem > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >