Proposal to include further supported Auth Models in the haystack protocol. The use of SCRAM model forces any haystack connection end point to also store users and hashes which as a security model is not always ideal. This is more commonly left to an auth service specifically built to do this in a secure manner. If SCRAM is left as the only supported AuthModel, this immediately prevents one Haystack service from communicating to the other that wants to implement their security model this way.

I know Basic Auth is frowned upon but SCRAM and/or Basic Auth are both equally susceptible to a man in the middle attack. The only benefit that SCRAM provides is it obscures the clear text password from that service but would not prevent access from the service in the middle from accessing the system as it would still maintain the ability to gain access to the authToken. The only way to make either of these auth models truly secure is over SSL.

I am not necessarily suggesting Basic Auth needs to be implemented but there is a real need for a haystack system to not have access to a user hash required for SCRAM authentication but still allow an incoming connection to be validated through some other mechanism.

Example: I want to build a haystack compliant application which requires communication from an existing haystack compliant application. This means the communication protocol would need to authenticate over SCRAM. But in my application, my users are all stored in LDAP and so I don't have access to any password hashes. My service can now not authenticate SCRAM connections but that doesn't mean my auth model is insecure, it just means I'm not able to implement SCRAM authentication model and so no haystack service could connect to my system.

Hi Jonathan. I definitely understand the need for haystack servers to have a standard way to delegate authentication to an external system (like LDAP). I think the simplest way to enable this functionality is to standardize a very simple plaintext authentication mechanism. It would essentially pass the username and password directly to the haystack server, and then you can do whatever 3rd party authentication you want.

I don't really see the need to even go as far as BASIC auth for this use case. A system like this should ideally only be used over TLS in the first place.

Before I proposed all the details of a "formal" method for doing plaintext authentication in haystack, do you agree with this approach?

I definitely agree there needs to be some sort of plaintext authentication allowed. Basic is a plaintext auth scheme already and well understood so i'm not sure if there is a need to design a different approach unless you have one in mind that can enhance the security of the Basic auth model.

We already have a standard, pluggable authentication protocol. We just need to enhance it to formally define plaintext. I would direct you to this thread for some of the background that led to the current architecture.

So I'm not really in favor of supporting the extendable mechanism we have now, and also basic authentication as an alternative. I need to investigate in more detail, but I think that after the initial HELLO message, we could support standard basic authentication, but I'm not willing to throw out the HELLO portion of the protocol.

It seems more straight-forward to just add a "PLAINTEXT" auth scheme, and send the username and password as base64uri encoded auth params.

I agree with Matthew. The basic design is built around RFC7235, and although "classic basic" kind of works with it, it is a special case which isn't extensible or pluggable. With our design using the hello message, the server gets a chance to decide on a per user basis what mechanisms are available and to list them to the client.

So I would vote for simple new plaintext mechanism be added to the scram mechanism within the existing request/response framework.

And I would support that the specification require that plaintext only be available over HTTPS when using TLS.