Authentication over SSL

[Julien ÉLIE]

Hi Russ,

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

I agree with you.  It would be very bad practice for clients, if any, which
implement that sequence.


>>   [1] If a TLS layer is already active, or if authentication has
>>   occurred, STARTTLS is not a valid command (see Section 2.2.2).
>
> 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.

That's right.  Thanks.


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

Indeed.  Just after STARTTLS, the TLS mechanism is given to SASL:

    sasl_setprop(sasl_conn, SASL_SSF_EXTERNAL,
                          (sasl_ssf_t *) &tls_cipher_usebits);
    sasl_setprop(sasl_conn, SASL_AUTH_EXTERNAL, tls_peer_CN);

Hmm... It makes me think that I should give it again to the SASL server
in case AUTHINFO SASL fails because it is now restarted (otherwise,
the SASL implementation is broken).

-- 
Julien ÉLIE

« -- C'est une bonne situation ça, scribe ?
  -- Oh, c'est une situation assise. » (Astérix)