Re: RSET command - possible security loophole
2011-06-01 18:02:23
Its says once authorized, you can't issue it again:
Old 2554:
Restrictions:
After an AUTH command has 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.
Updated to:
Restrictions:
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.
I think we are debating two things: the relationship between the
authenticated identity and that of the SENDER (MAIL FROM) of the
message, and how this applications to subsequent same session
transactions that have completed an initial transaction.
Personally, we need to look at it as what multiple transactions help
resolve as oppose to doing it separately. In the latter, each (AUTH)
can be different, but if thats the case, than these individual
messages should not be viewed as under the same group.
Practically, targets have properties of smart hosting, port, tls and
authentication requirements.
So to me, this is just am implementation queuing consolidation
heuristic design issue.
John C Klensin wrote:
Yes, exactly.
And the "only one AUTH per session" condition (which you
describe as "nly allowed before the first MAIL in the
session"... well, while 4954 could have imposed that condition,
I don't think it does (and, IMO, it would have been be really
bad design if it had)
john
--On Wednesday, June 01, 2011 17:24 -0400 Peter Bowen
<pzbowen(_at_)gmail(_dot_)com> wrote:
On Wed, Jun 1, 2011 at 15:39, John C Klensin
<john+smtp(_at_)jck(_dot_)com> wrote:
On Wednesday, June 01, 2011 12:09 -0400 Peter Bowen
<pzbowen(_at_)gmail(_dot_)com> wrote:
But this would be allowed, correct?
No, it is not. Â See below.
(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".
That is correct: unless some extension changes it, mail
transactions start with a MAIL command. Â Since RSET resets
any mail transaction that happens to be in progress, the
sequence above ought to produce a "command out of order"
response to the second RCPT command.
You are of course correct. What I intended did not make it
into the example. Corrected:
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: MAIL FROM:<whoever@wherever>
S: 250 Go ahead, I know who you are
C: RCPT TO:<highmucketymuck@wherever>
S: 250 OK, you're allowed to do that now
My point is that sending a RSET sets the state back to "not
during mail transaction", hence you can AUTH after RSET. The
other alternative is that AUTH is only allowed before the
first MAIL in the session.
Thanks,
Peter
--
Sincerely
Hector Santos
http://www.santronics.com
|
|