Subject: [Ace] test planning?

From: Jim Schaad <[email-masked]>
Date: Sun, 13 Oct 2019 18:47:29 -0700

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

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 15 Oct 2019 10:36:41 +0100

Hello,

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

> 1.  Post the token to the server before starting:

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?

> seem to be usable as none of the methods in 3 provide for server

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

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

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

> 1.  What requirements are there for validating the TLS client/server

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

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

> If not, doe the option of 4.a make sense and should it be documented as
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.
Thanks for this. I hope I was able to clarify some of the issues.

Sincerely,
--Cigdem

>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>