Authentication over SSL

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


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

> Hmm...
> You frighten me because I implemented that:
>
> AUTHINFO USER test
> 381 Enter password
> AUTHINFO PASS test
> 281 Authentication succeeded
> STARTTLS
> 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
layer?

> According to RFC 4642:
>
>   Syntax
>      STARTTLS
>
>   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
part.

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 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.


More information about the inn-workers mailing list