ietf-smtp
[Top] [All Lists]

Re: RSET command - possible security loophole

2011-06-01 11:26:08

On Wed, Jun 1, 2011 at 00:05,  <ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
-----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 
examples,
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 the
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.

But this would be allowed, correct? (Assuming no previous AUTH was sent)

C: MAIL FROM:<whoever@wherever>
S: 250 Go ahead, you unauthenticated thing you
C: RCPT TO:<highmucketymuck@wherever>
S: 559 Authorization failure, need to authenticate to send to this address
C: RSET
S: 250 State reset
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

Once the RSET is issued, I would think the state it is not "during a
mail transaction".

Thanks,
Peter