search

ace-wg / mqtt-tls-profile

Document for MQTT-TLS-profile
Other
0 stars 2 forks source link

Broker stores token for future use #88

Open ciseng opened 3 years ago

ciseng commented 3 years ago

AD-Review: 05/08/2021 Action: Fix as I proposed in my later comment.

Original draft: If the Broker accepts the connection, it MUST store the token until the end of the connection. On Client or Broker disconnection, the Client is expected to transport a token again on the next connection attempt.

Comment: This seems to deviate somewhat from the framework, that expects the RS to be prepared to store at least one token for future use, and recommends storing one token per PoP key.

ciseng commented 3 years ago

First comment: [CS: OK I will need to update the draft if I cannot have a deviation. Then,I need to think about how to implement it - I assume PoP will be done again if the client connects without a token, but RS believes there is a token associated with it?]

Futher comment from Ben: It may be okay to have a deviation, but I don't want to just "silently" have a deviation -- it should be noted as such, which indicates that we've actually thought about it. (The framework text seems to be "MUST be prepared to store at least one access token", not "MUST store at least one access token"...)

My final comment: [CS: OK.
Let me consider what happens if the Broker stores a token for future use. Then, different from the public clients, which connect TLS:none,MQTT:none, the client still connects to TLS:none,MQTT:ace, i.e. it gives the authentication method as ACE, but doesn't provide a token. We previously used this to signal optional AS discovery. If there is no token, but the method is ace, the first thing the Broker can do is to look for a token associated with the client. Then it does the AUTH challenge to do PoP of the token for this client. If this fails, or there is no token, then it sends a CONNACK not authorised, and does optional AS discovery.

I think flow-wise this can work - it is not a security issue if the client ids collide, and the broker considers a wrong token for the client because of the PoP challenge.

If this is acceptable, I will revise. ]

ciseng commented 3 years ago

At the end followed the framework, and said the Broker MUST be prepared to store a token for future use. In the case where the token is transported with authz-info then the Broker should be checking if a token was stored anyway. In the case where the token is supposed to be transported via CONNECT, and no token is present in Authentication Data, then the Broker should look for a token, and do a challenge-response based PoP.

for MQTT v3.1.1, the token is stored if it is transported via authz-info but then the Client MUST authenticate over TLS because challenge-response PoP is not possible. The Broker SHOULD still be prepared to store an access token for future use, e.g., client transports token for connect, disconnects, and then authenticates over TLS etc.

ciseng commented 2 years ago

This should be fixed with the text added in the previous comment.