D-Bus spec is not fully RFC-4422-compliant (not a conformant SASL protocol)
https://datatracker.ietf.org/doc/html/rfc4422#section-4 says that protocols that use SASL (like D-Bus) MUST provide:
-
(§4.1) "A service name, to be selected from registry of "service" elements for the Generic Security Service Application Program Interface (GSSAPI) host-based service name form." (We don't have one of these.)
- In practice, I think this omission means that not all SASL mechanisms will be implementable. The mechanisms we genuinely implement don't need this, so it has never been a practical problem.
-
(§4.3a) "A message to initiate the authentication exchange" (in D-Bus this is
AUTH
). It "MUST contain a field for carrying the name of the mechanism" (it does). "It SHOULD contain an optional field for carrying an initial response" (it does)- "The specification MUST describe how messages with an empty additional data are distinguished from messages with no additional data" (spec bug: we do not do this).
- "This field MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets)." (spec bug: we use hex-encoding to be able to send any octet, including 0x00 encoded as 00, but we don't say how zero-length sequences are represented).
-
(§4.6) "Identify precisely where newly negotiated security layers start to take effect"
- We don't. In practice we don't support security layers that alter the content of the stream.
-
(§4.8) "Indicate whether the protocol supports multiple authentications"
- It doesn't, but we don't say so.