Authentication over SSL

Russ Allbery rra at
Tue Sep 23 17:25:45 UTC 2008

Julien ÉLIE <julien at> writes:

> Hmm...
> You frighten me because I implemented that:
> 381 Enter password
> 281 Authentication succeeded
> 502 Already authenticated

That's fine according to the standard.  I think the point is more that a
client doing that isn't particularly sane.  If you're going to use
encryption, why authenticate before you've established the encryption

> According to RFC 4642:
>   Syntax
>   Responses
>      382 Continue with TLS negotiation
>      502 Command unavailable [1]
>      580 Can not initiate TLS negotiation
>   [1] If a TLS layer is already active, or if authentication has
>   occurred, STARTTLS is not a valid command (see Section 2.2.2).
> And I understood that STARTTLS could not be sent after AUTHINFO
> (but the contrary is possible).
> Note that section 2.2.2 does not explain further that behaviour...

Section 2.1 also says that you're not allowed to advertise STARTTLS after
a successful authentication.  The cross-reference is for not sending
STARTTLS after successful STARTTLS, rather than for the authentication

As I recall, the main reason for the restriction on the order of STARTTLS
versus authentication is that SASL can negotiate its own privacy layer, in
which case the standard requires that you negotiate TLS first and then the
privacy layer of SASL on top of it if you're using both at the same time.

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list