Hello, Thank you, Jim, for this plan. Responses are inline.
On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
