[Top] [All Lists]

RE: RSET command - possible security loophole

2011-05-31 23:35:33

-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Tuesday, May 31, 2011 3:29 PM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: RSET command - possible security loophole

Authentication (AUTH) and session security (STARTTLS) are the obvious 
but it is also very common for implementations to support proprietary
mechanisms to allow setting of various session attributes (including but not
limited to the real IP address of the client). Various sorts of proxies are 
usual use-case for this stuff.

Sorry, right, AUTH and STARTTLS of course.  My point is that once you hit
MAIL and thus begin message-specific operations rather than
connection-specific ones, I can't think of any SMTP commands that go back
and potentially alter session state in any obvious way that I can think of.

Goodness, I certainly hope not. We discussed the possibility of allowing
someone to authenticate back when SMTP AUTH was first being specified. There
were a couple of people who wanted to allow this sort of thing:

    C: MAIL FROM:<whoever@wherever>
    S: 250 Go ahead, you unauthenticated thing you
    C: RCPT TO:<highmucketymuck@wherever>
    S: 559 Authorization failure, need to authenatice to send to this address
    C: AUTH blah blah blah
    S: 250 OK, you're authorized now
    C: RCPT TO:<highmucketymuck@wherever>
    S: 250 OK, you're allowed to do that now

I protested vehemently that the resulting security semantics would be a HUGE
mess. Just as one example, supppose the AUTH would have impacted the semantics
of the previous part of the transaction in some way, e.g., a recipient address
that looks successful but got silently blackholed because of the
lack of authorization.

No, the only way for this not to degenerate into madness is to disallow
session-changing stuff during a mail transaction.

What am I missing?

Stated this way, nothing.


<Prev in Thread] Current Thread [Next in Thread>