STOMP Authentication Proposal

[Benjamin Roux]

Hello everyone,

I would like to submit a proposal for a more exhaustive authentication mechanism for STOMP to replace the weak login/passcode solution.

This would be part of a possible STOMP 1.3 specification.

(The usage of MAY, SHOULD, MUST etc... is not definitive and is mostly incorrect at the moment).

Let me know what you think.

-Benjamin

-------------------

Problem Statement

STOMP provides simple login/passcode authentication scheme. In the day and age of distributed systems and multi-tenant services, login/passcode is not always a suitable or secure enough mechanism to authenticate users/customers/tenants.

Proposed Solution

In the document STOMP 1.3 might be mentioned. It refers to STOMP with the following authentication mechanism.

SASL Authentication

Introducing a new multi-step authentication mechanism built on top of SASL.

SASL (Simple Authentication and Security Layer) is a framework for authentication and data security in Internet protocols. It is standard and implemented by multiple products/protocols such as Apache Kafka, memcached or SMTP. It supports multiple authentication mechanism such as PLAIN (equivalent to login/passcode), OAUTHBEARER (OAuth), or CRAM-MD5 (challenge based) and more. Companies or providers can also implement their own mechanisms.

In order to support SASL, small modifications to STOMP have to be made.

The new authentication flow will look like:

CONNECT → AUTHENTICATE → AUTHENTICATE → ... → CONNECTED

Upon connection the client will issue a CONNECT frame like today. STOMP 1.2 and lower will still support the basic login/passcode authentication scheme in the CONNECT frame. STOMP 1.3+ CONNECT frames will need to specify which SASL mechanism they wish to use to authenticate themselves by using the new mechanism header.

If the server doesn't support the requested mechanism it will reply with an ERROR frame. The content should contain the supported mechanisms by the server. 

Otherwise, the server will reply with an AUTHENTICATE frame with the mechanism header set to the mechanism that is going to be used (this is simply for confirmation to the client). A body is not be required in the frame.

The SASL authentication will now be initiated by the client through an AUTHENTICATE frame containing the required content based on the selected mechanism. Because the content may contain NUL characters it is recommended to specify the content-length header to prevent parsing errors by the server.

If the authentication mechanism is multi-step (like CRAM-MD5 for example) the server will keep sending AUTHENTICATE frame with the required content (challenge for example). For each AUTHENTICATE frame sent by the server, the client must send back a corresponding AUTHENTICATE frame to keep proceeding with the authentication.

Upon successful authentication, the server will finally reply with a CONNECTED frame.

Upon failed authentication the server will send an ERROR frame which may contain detailed information.

Re-authentication

Periodic re-authentication will also be supported through an optional re-authentication header in the CONNECTED frame. The value is in seconds and clients should re-authenticate themselves using the same mechanism used during the initial authentication before "re-authentication" seconds. Re-authentication is initiated by the client by sending an AUTHENTICATE frame with the required content for the mechanism. That frame will re-trigger the authentication flow as described above. Attempting to use a different mechanism may result in an error since the server will not be processing it properly. The re-authentication header value may be different from one authentication to the other because the validity of the underlying authentication token may change (for example at the time of connection #1 an OAuth token might only be valid for 30 minutes, while upon connection #2 it might be valid for 20 minutes, in which case the header value will be different).

Frames received by the server before the AUTHENTICATE frame must be processed under the assumption that the authentication is still valid. If re-authentication fails, such frames should still be processed. While re-authentication is happening clients should refrain from sending non-authentication related frames but the server may queue them and process them once re-authentication has been successful. If re-authenticate fails, any frames received after the client-initiated AUTHENTICATE frame will not be processed by the server.

If the client doesn't initiate a re-authentication before the re-authentication timeout and the server receives a non-authentication related frame, the server must send an ERROR frame and close the connection. Authentication-related frames received after the timeout must be accepted and processed by the server.

Because of timing inaccuracies, the server should be tolerant and take into account an error margin. However clients should also take timing into account and initiate re-authentication in a timely fashion before the timeout (timeout - 10% as a rule of thumb).