Hi all, There is still one open item pending for SCRAM that has not been treated which is mentioned here: https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi
When doing an authentication with SASL, the server decides what is the mechanism that the client has to use. As SCRAM-SHA-256 is only one of such mechanisms, it would be nice to have something more generic and have the server return to the client a list of protocols that the client can choose from. And also the server achnowledge which protocol is going to be used. Note that RFC4422 has some content on the matter https://tools.ietf.org/html/rfc4422#section-3.1: Mechanism negotiation is protocol specific. Commonly, a protocol will specify that the server advertises supported and available mechanisms to the client via some facility provided by the protocol, and the client will then select the "best" mechanism from this list that it supports and finds suitable. So once the server sends back the list of mechanisms that are supported, the client is free to use what it wants. On HEAD, a 'R' message with AUTH_REQ_SASL followed by SCRAM_SHA256_NAME is sent to let the client know what is the mechanism to use for the SASL exchange. In the future, this should be extended so as a list of names is sent, for example a comma-separated list, but we are free to choose the format we want here. With this list at hand, the client can then choose the protocol it thinks is the best. Still, there is a gap with our current implementation because the server expects the first message from the client to have a SCRAM format, but that's true only if SCRAM-SHA-256 is used as mechanism. In order to cover this gap, it seems to me that we need to have an intermediate state before the server is switched to FE_SCRAM_INIT so as the mechanism used is negotiated between the two parties. Once the protocol negotiation is done, the server can then move on with the mechanism to use. This would be important in the future to allow more SASL mechanisms to work. I am adding an open item for that. For extensibility, we may also want to revisit the choice of defining 'scram' in pg_hba.conf instead of 'sasl'... Thoughts? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
