Re: [Fwd: [Asrg] Re: Documents for LMAP BOF]

Hadmut Danisch wrote:
> On Sat, Feb 07, 2004 at 09:00:19PM -0500, Yakov Shafranovich wrote:
> 
>>    http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt
> 
> 
> Ok, here are a few comments:
> 

Thanks!

> 1.1. Summary of the Protocols
> 
>    LMAP is based on two concepts: publication of authentication
>    data by a domain, and application of that data by a recipient
>    MTA.
> 
> 
> As you can see from changes in RMX draft, I first called
> the mechanism an authentication, later I called it an authorization. 
> While the difference is merely philosophical, you should be very
> careful to choose correct wording if you want to persist against
> professional security researchers. But it is not obvious, whether
> this is really authentication or authorization.
> 
> You could call it authentication because it answers the question 
> "Are you someone@somedomain?" But I don't think that's correct.
> 
> Actually, authentication is done by a different mechanism. It is
> the TCP sequence number. It authenticates the caller to be the 
> one identified by an IP-Address. The IP-Address is the identity, 
> not the e-mail address. And you answer the question 
> "Is x.x.x.x permitted to use the address someone@somedomain?"
> 
> Therefore, I do see that solely as an authorization mechanism, 
> which makes use of the implicit TCP authentication. 
> 
> (See http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt
> why I believe it is important to distinguish between authentication
> and authorization.)
> 

What about something like this:

" LMAP is based on two concepts: publication of authorization
   data by a domain, and application of that data by a recipient
   MTA.
"

or perhaps like this:

" LMAP is based on two concepts: publication of policy
   data by a domain, and application of that data by a recipient
   MTA.
"

>    The data published by a domain includes statements as to which
>    IP's are permitted to originate mail from the domain in SMTP
>    EHLO/HELO and MAIL FROM.
> 
> It might be to late to incorporate it into the draft, but you 
> should have a look into Microsoft's CallerID draft. They elaborate
> how to do this all based solely on header information. I'm not yet
> sure whether this works in all cases and whether it is advisable.
> But it should be definitely taken into consideration.
> 

I believe that SpamAssasin's implementation of SPF looks at headers as 
well since it does not have access to the SMTP session information. 
Since MSFT has so far not submited its draft to the IETF, we would 
include something along the following without referencing them directly:

"It is also possible to verify LMAP data by parsing the Received headers 
of the message, although this method is not as fool proof or reliable as 
doing so at the MTA level. Additionally, spammers may choose to fake 
Received headers, further complicating such analysis."

We have until February 16th to submit a -01 draft.

> 
>    E-mail from LMAP domains that do not publish LMAP data should
>    NOT be rejected since there is no requirement that domains do
>    so, and many will not, either for policy reasons or from lack
>    of resources.  E-email from non-LMAP domains should be treated
>    as e-mail is treated today.
> 
> Urks. If it is treaded as e-mail is treated today, then it is
> treated as spam is treated today. :-(
> This means that spammers don't use yahoo, aol, hotmail, but any
> other of the millions of domains.
> 
> Modify this recommendation, give it a time limit. Should not be
> rejected until 1.1.2005 (or any other date). From then it's up to the
> receiver whether to accept or reject it. Tell people to be aware 
> to risk being blacklisted without an entry then.
> 

We cannot put in a flag day. Until LMAP is deployed widely, it would 
have to be used as a whitelisting method or something that raises the 
likehood of a message not being spam. It is very possible that wide 
scale deployment might take years so putting a specific date will cause 
problems. I think that the statement that non-LMAP data can be treated 
as it is today is sufficient.

Keep in mind that LMAP is not seen as the only solution to spam, rather 
it is a solution for one specific aspect of it - forgery of SMTP session 
information. Therefore, it is expected that implementations will use it 
in combination with other solutions. Therefore we might want to add to this:

"It is expected that LMAP will be used in combination with other 
anti-spam techniques."

> 
> 2.2. Choice of data to authenticate
>    When a message is sent via SMTP, the recipient MTA has a
>    variety of items that it could use to authenticate the mail
>    sender.  In the order that they are available to the recipient
>    MTA they are:
> 
> 2.2.1 IP address
> 2.2.2 HELO/EHLO name
> 2.2.3 Return path
> 2.2.4 Message header fields
> 2.2.5 Comparison
> 
>    All of these items, IP address, HELO/EHLO argument, return
>    path, and message headers, can be used for various kinds of
>    authentication.
> 
> 
> It strongly disagree, because I believe that the structure of the 
> text is wrong. It mixes and confuses things that should be kept
> separate:
> 
> - There's an IP address. It's an identifier for the party you're 
>   talking with. Regarding to what I stated above this is the identity
>   of the caller authenticated implicitely by TCP.
> 
> 
> - There is an e-mail address/domain name (in fact, there are several,
>   the envelope sender, the HELO name, all those in the header like 
>   From: Reply-To: Forwarded-By:..., anyone is chosen), which is the 
>   resource the caller tries to use. We are going to check whether the 
>   caller is permitted to use it. However, this is a completely
>   different kind of object than the IP address, and thus should not be 
>   mixed with it in the same itemization.
> 
> - There is a lookup key used to find the auth record. The idea is to 
>   have a function 
>   
>     f(e-mail-address) -> DNS lookup key
> 
>   so the lookup key is derived from the e-mail address (simply by
>   cutting away the local part or anything like that).
>  
> 
> Therefore I recommend to keep these three classes of identifiers 
> strictly separated. That's a matter of security engineering.
> 

So basically there are:
1. IP address of the MTA.
2. Information about the sender.

and within the FROM information we have:
a. domain in HELO.
b. domain in MAIL FROM.
c. domain in the headers.

There are two types of authorization possibilities here:
1. Whether the incoming IP is authorized to be an MTA.
2. Whether the incoming IP is authorized to use the domain.

I do not see a third identifier, perhaps you can elaborate?

> 3.2.1 SUBMIT (port 587)
> 
> I doubt that choosing a different port is a solution to any 
> problem. That's security by obscurity.
> 
> The reference is missing
> 

RFC 2476:
http://www.faqs.org/rfcs/rfc2476.html

> 
> 4.1. DNS record types
> 
>    RMX: defines two new record types, RMX and APL
> 
> 
> RMX does not define APL records. They are an RFC on their
> own written by someone else.
> 

RFC 3123:
ftp://ftp.rfc-editor.org/in-notes/rfc3123.txt

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Among all our enemies / The ones to be most feared are often the 
smallest" (Jean de la Fontaine)
-------