Re: [Ace] test planning?

[Cigdem Sengul <[e-mail]>]

Hello,

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

On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>