Thank you, Jim, for the comments. I have created issues corresponding to each one in the GitHub repository.
We will start working on them, and specifically clarify the issues 1-3 around the CONNECT message. For 4, MQTT v5 can support a challenge-response; not possible with v3 indeed. Will expand the security considerations section on that. 5. We described a convention in the draft with SHOULD. Do we turn that into a MUST? 6. We thought that the AS would dictate the token expiration time. It can also be done that RS times out tokens even if they have not expired. But, security-performance trade-off should be considered. Token caching is important even if the token does not need introspection. The only time the MQTT client can push a token is with the CONNECT message (all subsequent publish/subscribe messages rely on this). In MQTT v5, a client can push a new token via reauthentication during an ongoing session (enabled by MQTT v5). If RS times out the token, this means a disconnection in MQTT v3. We mention this in Security considerations as "it is expected that AS follows a reasonable expiration strategy for access tokens" -->There may be workarounds designed especially MQTT v5 which has better support for request-response style communication. But need to think about it. 7. That is correct. Will add the clarification. Thanks, --Cigdem On Wed, May 22, 2019 at 10:58 PM Jim Schaad <i...@augustcellars.com> wrote: > Thanks for the updates from my last message. This has helped quite a bit. > > 1. A discussion of the use of raw public keys rather than certificates for > the server may be in order. This can refer to the same RPK issues from the > current DTLS document. It may also be that this just uses normal > certificate processing and that should be noted as well, but some > discussion > of deciding if the subject name/alt name matches the token returned from > the > AS. > > For the connect message there are a couple of issues that need to be > thought > about. > > 2. What items are required to be in the connect message. The response to > my last message suggested that a client identifier is required to be > present > but that is not documented. > > 3. It is not completely clear what portions of the CONNECT message are > being covered by the signature/MAC value. As an example, is the password > field omitted entirely or is it set to a zero length password. In addition > to this, from the couple of implementations that I have looked at the > entire > packet is not passed out of the base server code for authentication > purposes. This might need to be taken into account in terms of what is > used > for the body and how it is constructed. (As a side note, the > implementations that I have looked at so far also think that the password > is > a text string rather than a binary value which is going to be a short term > issue as well.) > > 4. I must admit that I am disappointed that there is no challenge response > mechanism in the MQTT specifications. I don't know that anything can be > done at this point about it but there are some security issues that need to > be highlighted because of this in the security considerations section. > Only > the v3 seems to have this problem. Also doing the channel binding would > deal with this problem as well. Might just need some general discussions > around the channel binding text. > > 5. Is there an intention to provide a "standard" format for the scope > field > or just to leave it as ad hoc? > > 6. It might be reasonable in section 2.1.3 to note that even if a result > is > cached, that cached check should be limited for a specific amount of time > to > recheck if the token is still active. More of an issue in terms of how > long > to cache for introspection. > > 7. In section 2.1.4 - I would presume that the last paragraph should be > extended to say that the token is stored only for the length of the > connection. That is the token always needs to be supplied every time a > connect message is sent. > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
