----- Original Message -----
From: "Edwin Aoki" <aoki(_at_)aol(_dot_)net>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Thursday, March 11, 2004 2:04 PM
Subject: Re: Authentication and Authorization
There are multiple entities being authenticated and multiple decisions
made to authorize. Let me see if I can try to put this into an example:
In my analysis you have 50-55 scenarios! :-)
I (Edwin Aoki, aoki(_at_)aol(_dot_)net) try to send a piece of mail to (for
example) Dave Crocker.
In my mind, here are the various sender assertions that could be made
(without reference to any specific proposal):
* I, Edwin Aoki, authored (created) this message
* I, Edwin Aoki, sent (caused to be injected into the mail stream) this
message
* A machine at 1.2.3.4 is authorized to send mail
* A machine at 1.2.3.4 is authorized to send mail on behalf of AOL
(aol.net)
How about a real example with a real AOL.COM transaction as captured by my
logs. Maybe you can shed some light into this:
ip: 172.176.112.164
helo acb070a4.ipt.aol.com
mail from: <ryohei(_at_)seznam(_dot_)cz>
rcpt to: <hector(_at_)winserver(_dot_)com>
Keep in mind the following:
My LMAP validation and trust analysis has shown that factoring in all
envelope parameters plays a major role in LMAP conclusions and specifically
how each SPF and DMP differ. In addition, LMAP is for final destination
only and local spoofing has been eliminated from the picture.
In this example, there are no DMP records, so this would be a "no decision"
result.
For SPF, both domains offer a SPF policy with the following possibly result:
FROM domain: softfail
HELO domain: none (when using subdomain SPF lookup)
HELO domain: neutral (when using the parent domain SPF lookup)
So here we have a "mixed policy" situation and the question is, who
provails?
If the HELO domain says the machine is part of a SPF domain network, then
the assertion is that the machine is valid as a sender.
In other words, the only possible SPF results for a HELO lookup is none,
pass or reject. Nothing in between. No neutral or softfail.
This goes back to the assertion that the originating MTA established an
authenticated session with the user and internal domain routers were within
a trusted network. This can only be broken if the sender machine is also
a receiver and it is an open relay. Analyzing how the message could of
been injected into the aol.com network, a direct connect on port 25 to
acb070a4.ipt.aol.com is not available, hence one possible topology for this
would have to be:
MUA --1--> aol.com --2--> acb070a4.ipt.aol.com --3--> winserver.com
Transaction #1 must be an authenticated session in order for the originating
MTA (aol.com) to allow the relay to winserver.com.
Once injected into aol.com, transaction #2 "must" be trusted. If this is
not the case, then in my opinion, then all bets are off with SPF (or LMAP in
general).
Even if the topology was single hop:
MUA --1--> aol.com ---3--> winserver.com
what it says is that the sender machine must first be validated as a
possible sender before the return path domain LMAP relationship can be
determined.
May question to you is how is this transaction possible? I can only assume
it is legitimate as it comes from a AOL.COM machine. In a system with
mixed policies, it may suggest that the client domain (helo) may have a
stronger role in the final outcome.
In summary:
1) LMAP Proposals need to review Mixed policy situations.
I am nearly finished with my LMAP trust analysis which show 45 to 50 of the
total 55 possibiliies with mix policy situations. I think this is basically
showing how HELO results can alter the FROM results and vice versa. I am
already seeing many of these mixed policies situations in my logs as I
showed above. I have not concluded whether they provided false negatives
or false positives yet.
One thing for sure.......
2) All LMAP proposals with relaxed policies should be eliminated as ASAP
We need don't the same problematic design issues that got us here in the
first place with relaxed SMTP functional specifications. LMAP concepts such
as SPF neutral or softfail need to be temporary. In fact, maybe a
recommended transitional period of X months should be expected once a domain
exposes a SPF policy with relaxed results. Just yesterday I saw a spammer
trying 3-4 sessions with different return path domains each with
SPFsoftfail or neutral records.
3) Clarification on the new Received-SPF header.
Not sure if this is important, but when it is added? Before the normal MTA
addition of Receive: or after? I'm seeing messages out there with both.
Soon SPAMMERS will just need google "Received-SPF" to look for vulnerable
neutral/softfail sites.
Do we need this type of "advertising" exposing exploitable MTA? I mean,
sure for post validation systems, but if a transaction is deemed 100%
acceptable, I don't think it needs a SPF header.
4) Any LMAP proposals with redirection concepts need redirection protection.
For example, with the SPF directive "redirect," SPF can be enhanced to have
a new directive that says NOR, "no redirections."
5) LMAP DNS Policy Record Spoof protection.
Not as simple as redirection protection, all LMAP proposals need a concept
so that LMAP DNS domain policies can not spoofed or borrowed by others.
This may simply be answered by going back to the mixed policy concept which
I
believe shows the IP/HELO association *may* has a stronger trust requirement
over the IP/FROM association.
Also, I am thinking of a "secret" password concept on the LMAP policy
coupled with a SMTP protocol level challenge string here.
6) LMAP proposals needs review on how HELO lookups are done, subdomain or
parent?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com