require_ssl with SASL secure layers

[Julien ÉLIE]

Hi all,

> I think we could rename the require_ssl: parameter in readers.conf
> to something like require_encryption: in order to take into account
> both a successful STARTTLS command (or "nnrpd -S") and a successful
> AUTHINFO SASL with a negotiation of a secure layer.

I am facing a problem with that.
AUTHINFO SASL is a bit magical and does not use auth groups...

What I manage to do is when every auth group has require_ssl: set to
true, we prevent people from using AUTHINFO SASL PLAIN/LOGIN/EXTERNAL,
as well as AUTHINFO USER/PASS.  (This behaviour was previously only
done with TLS support because require_ssl: was valid only when compiled
with --with-openssl.)


But afterwards, I don't always have the possibility to associate an access
group with encryption required.

auth1 {
  key: "1"
  require_ssl: true
}

auth2 {
  require_ssl: false
}

access1 {
  key: "1"
  post: "*"
}

access2 {
  read: "*"
}

If AUTHINFO SASL negotiates a security layer, the user cannot use access1
because there is a key and AUTHINFO SASL did not bind to any auth group...
It will bind to access2.


This key: problem is generic in our SASL implementation with readers.conf;
it does not depend on require_ssl: and I do not know well how to handle that.

Something is missing in our SASL implementation...  Maybe a sasl_auth:
parameter in an auth group?  And the first one that matches will be used?
This parameter would be true/false.  (Or another name like sasl_allowed:
or... a list as Jeff suggested "*", "!*", "*,!LOGIN", "CRAM-MD5,OTP"...)
The default would be "*".
At the same time, while parsing auth groups after authentication, we can
see whether a secure layer has been negotiated and decide to keep or not
the auth group, etc.


Any thoughts about that?  Other suggestions?

-- 
Julien ÉLIE

« Quand tu auras lu ces lignes, le papyrus s'autodétruira. » (Astérix)