[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-31 17:56:54

SM wrote:

Hi Hector,
At 12:58 31-05-2011, Hector Santos wrote:
In regards to authentication, in our code, for IP based (Relay Tables, POPB4SMTP), it can not change the authentication based on IP. For ESMTP AUTH, once the session authenticated, per RFC2554, section 4, it will not allow another AUTH to be issued with a 503 response.

Is your implementation compliant with RFC 2554 or RFC 4954?

Our server is compliant with RFC2554 and related AUTH docs in regards with RFC3207 (TLS) and RFC4409 (SUBMIT), i.e. important sequence to follow.

I don't recall using the update RFC4954 nor searching "4954" in the source code show any specific references which is normally how we annotate RFC update related protocol logic changes.

A quick perusal seems to show it combined many of the related docs. i.e. TLS, SUBMIT.

It seems the same restriction in 2554 was carried over to 4954 in section 4:

       After an AUTH command has been successfully completed, no more
       AUTH commands may be issued in the same session.  After a
       successful AUTH command completes, a server MUST reject any
       further AUTH commands with a 503 reply.

       The AUTH command is not permitted during a mail transaction.
       An AUTH command issued during a mail transaction MUST be
       rejected with a 503 reply.

So a RSET, imv, must not alter this authentication condition because the client has a protocol design restriction (thus not coded to re-authenticate) and the server will not allow it anyway. Our server will issue an AUTH response:

      503 Invalid AUTH request. Already Authenticated

Same applies with IP based because there is no way for the client to change the IP during the same session.

Like Keith indicated, we don't have a "logout" feature.

Anyway, I don't quite see the complication with authentication and "reset" because there is nothing in SMTP AFAIK that currently allows it.

On a related note, there is one change our SUBMIT server does in regards to authentication and the growth of NATS usage. This was noted to Klensin and Resnick to relax the EHLO checking requirements until the AUTH state is determined.

Since 4409 requires AUTHentication, it can delay the EHLO checking because depending on the MUAs being used on a private network LAN going over the wire with a NAT public address, there will be potential of an IP mismatch.

For example:

    Connecting client IP:  <---- NAT public address
    S: 220 ESMTP Server ready
    E: EHLO []            <---- IP where MUA is on LAN

This would be an SMTP violation enforceable under port 587 (RFC4409) operations.

So our SMTP server has an option (on by default) that when port 587 is active, it will relax this EHLO IP literal filter check until the pending and required AUTH state is determined.

That was the workaround until the popular Thunderbird MUA was updated and TBIRD now offers MTA options to set the EHLO client domain name or IP literal since its not easy to detect what will be the NAT public address. Since it was a quick fix, no user UI was added and it must be done manually by editing the config file under TOOLS | OPTIONS | ADVANCED.


Hector Santos