[Ace] test planning?

[Jim Schaad <[e-mail]>]

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