[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-31 00:34:52

John C Klensin wrote:
I think it is one of those items to write/jot down in a "Keep
In Mind" todo list so that when a RFC5321bis is ever pursued,
we could bring it up, debate and address it among other things
that might be considered for a bis.

You could certainly do that.  The only advantage of errata is
that they get tracked and not lost.

Ok, but I was not begging or voluntary for one neither :).

But, again, I don't think
there is a 5321 issue here at all and my suggestion was about
errata to the various extension documents, not to 5321.

I agree there is no 5321 issue. I like RFC5321 because it does provide great operational insights unlike other documents and I can only hope it stays that way.

Even if 5321 were changed to insert an "authenticated state", with RSET affecting the mail transaction state only, extensions would still be obligated to explain how much state RSET changed.

I was not even going there and I apologize if I expressed it incorrectly. I meant there are some points to discussed, but I that wasn't the issue with this topic.

But, IMO, we wouldn't want to make that change because there are
actually two different authentication models as far as the state
table is concerned:
S: 220... (connection state)
  C: EHLO (starting session state)
  C: MAIL FROM< (starting mail transaction state)
  C: <Sending mailbox authentication> (starting type 1
authentication state)

S: 220... (connection state)
  C: EHLO (starting session state)
   C: <Sending session/ client system authentication> (starting
type 2 authentication state)
 C: MAIL FROM< (starting mail transaction state)

Yes, ESMTP AUTH, etc, or just plain old Allow Relay IP at the connect level.

I wasn't going there and I guess because, from my SMTP design standpoint, once you authenticated, the SMTP level filter crap doesn't apply. We never wanted to add this stuff anyway and its only done after recognizing (like the world too) the massive abuse with anonymous, unsolicited, non-authenticated sessions.

I did not mean to imply RSET will change that authenticated condition which ever way that was determined:

     Allow IP Relay Tables
     POP B4 SMTP


Would one want the same behavior from RSET for both
arrangements?  Probably not, although it could be specified
either way.

Not for the traditional authentication methods. This is information that must be preserved, but it isn't the issue at hand and now I can see how RSET is not the only issue in regards to the topic in hand. See below.

The reality is, as I presume you may agree at some level, SMTP
today is not a pure "stand alone" application. It is highly
integrated and "feature rich" with security related policy
concepts playing a greater role.  The flexible reply codes and
guidelines to follow it, allow for any kind of future state
machine to work very well.

Yes.  But, with the current definition and model that "future
state machine" has to be specified as part of whatever
extensions cause it to be appropriate or necessary.   There
isn't any magic that changes the SMTP state machine itself.  One
could revise the model itself, but the result wouldn't be 821/
2821/ 5321 SMTP any more.

I agree that SMTP is perfect. :) And now I can see how not just RSET but other commands apply to this "security" topic. Once a "security policy-based" condition is determined, there is reasonable logic to disallow any further continuance short of dropping the client.

In other words, using the new RFC5321 explicit "enhanced" description for 450, 550 used for "policy reasons", it could mean no further state machine advancement or resets will be allowed, i.e, no transactions will be accepted during the current session.

As Derek pointed out, there are different transactions with
RSET and SMTP was designed to handle it independently
(correctly IMV).  I don't believe its a matter of stupidity or
one suggesting a spec not having the foresight. Its simple
more about current realizations about new SMTP integration
needs (which I personally believe applies to most, if not all,
operations) and I just was noting as general as I can, there
might be additional specific "security" related exceptions to
the RSET semantics.

We may just need to agree to disagree here, but, from my point
of view, the SMTP semantics of RSET is quite clear and just
fine.  The only relevant SMTP state is "mail transaction" and
that is what RSET resets (it does not, for example, reset the
server capability announcement returned in the reply to EHLO.
If some extension comes along and specified additional state(s),
it is obligated to specify what happens to those states in the
presence of RSET.  If it doesn't do so, that spec is defective
(not a problem with 5321 or new semantics for RSET).  If it
specifies that RSET discards, e.g., the authentication
information (perhaps by making the extension state part of the
mail transaction state) then my claim is that starting a new
mail transaction without noticing that authentication
information is no longer valid, then I repeat my belief that
would be a dumb (or at least careless) implementation, not much
different in practice from accepting the sequence:


and assuming that the second RCPT could reuse the data from the
first (only) MAIL command despite the RSET.  I can imagine
someone trying to justify that on the grounds of robustness, but
the risks are such that I'd think it would be dumb (as well as
fairly clearly non-conformant).


Yes, and its unbelievable how this strayed off course. I did not mean to imply RSET cleared authentication information, especially if its traditional IP based authentication - can't reset the IP (under the same session)! :)

The issue here was a DATA (or any state for that matter) rejection based on local security policy and the RSET (or even EHLO, MAIL) clearing information about "a security condition" from the last transaction in the same session now possibly lost when/where a new transaction begins.

I guess in principle, once that "condition" is determine (by whatever means), it applies to any subsequent new transaction is what I am describing.

And yes, this really has nothing to do with SMTP itself, its rather perfect and starting a new transaction is well defined and has worked perfectly for us.... except now we have new conditions based on external information at the SMTP level and it may mean the state machine logic changes at the implementation level (not the spec). At least, that is how I see it and having insights are good, not bad.



Hector Santos