Authentication over SSL

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

>>> Is it the same for AUTHINFO SASL?  If there is no auth parameters, it
>>> should not be advertised.

>> I forget how the SASL support works.  Is there anything in the
>> readers.conf file saying "support SASL" or is it entirely internal?

> Nothing in readers.conf AFAIK.

In this case, I think we have to always advertise SASL if built with SASL
support.

>> You definitely want AUTHINFO USER to fail if you don't want the user to
>> authenticate, since that prevents sending the password over an
>> unencrypted connection.  502 is the correct error code.

> All right, because 483 would be if there was a possibility to
> authenticate after STARTTLS.

Oh, hm, yes.  If that's available, we should return 483 instead.  I forgot
about that.

> Hmm...  What for:
>
> auth "nothing" {
>   hosts: "*"
> }
>
> access "nothing" {
>   users: "<all>"
>    read: "!*"
> }
>
> auth "users" {
>   hosts: "*"
>   require_ssl: true
> }
>
> access "users" {
>   users: "<all>"
>   read: "*"
> }
>
>
> GROUP -> 502
> AUTHINFO -> 502
> ...
>
> No authentication possible but if 483 is sent, the client maybe will
> negociate an encrypted connection and then have access to everything!

Right, we should return 483 here, if we can detect this case, to the GROUP
command and probably to AUTHINFO as well.  Good catch.  It might be hard
to detect that we're in this case, though.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.