Subject: RE: [lemonade] Comments on PUSH and PULL drafts

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 2 Mar 2004 16:20:09 -0600

Thanks for the quick reply, i'd like to come to better understanding in these hours before our face-to-face.

TLS/SSL hides addresses over the network, but that is not the threat I am concerned with.  The threat is that an attacker will gain control over the Submission server and use it to harvest credentials buried within the inner security ring of a service provider.  In general, connections from the dirty internet are to bastion, sacrificial servers with minimal value-add, and which pass the protocol or data to a more trusted host within the defended network.   It is this model I want to support with any solution we deploy.

Again, it may be possible to support this with an SMTP-level protocol proxy, but if I already have an IMAP-level proxy, then I'd rather re-use it.  And of course, Ned loves to tell stories about how brain-dead SMTP proxies have made the world a better place :-(  I'm sure you can tell stories of why IMAP proxies are equally nasty.  Maybe we can agree that one of these things is better than two?

In the interests of addressing my needs within the context of the pull proposal, can you describe what new developments in the past ten years make my customers paranoid DMZ-based approach less necessary?  I see only further examples of such paranoia, such as enterprises allowing submission only from clients residing within the corporate network, an inconvenience requiring me to use a VPN or SSL to send mail from the IETF!

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Wednesday, March 03, 2004 6:33 AM
To: Vaudreuil, Greg M (Greg)
Cc: Rob Siemborski; Marcus D. Leech; [email-masked]
Subject: RE: [lemonade] Comments on PUSH and PULL drafts

On Tue, 2 Mar 2004, Vaudreuil, Greg M (Greg) wrote:
> While submission servers can and should authenticate using per-user 
> credentials, this still seems to be an operational exception rather than 
> the rule.

Is that really true?  None of the submission servers that I have access to 
permit access without per-user credentials.

>  - For ISP's and the like, the submit server lives in a DMZ-like 
> environment where there are requirements to limit access to sensitive 
> data like user credentials. It is more "secure" from some perspectives 
> to authorize based on source IP address (is it on my network) than to 
> expose and use per-user authentication.

This observation may have been valid 10 years ago, but subsequent events 
have overtaken it.

The technology of IP address spoofing is well-developed and used by the 
bad guys to defeat those who believe that source IP address validation is 
good enough.

Authentication technologies exist that do not convey useful information to 
a third-party monitoring the authentication.

SSL/TLS is widely deployed, and effectively defeats monitoring.

New technology being defined today should consider the environment being 
deployed now and in the future, and not create needless dependencies on 
the environment that was deployed in the past.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Tue, 2 Mar 2004 15:23:23 -0800 (Pacific Standard Time)

Much of this becomes clearer when you consider a SUBMIT server to be a 
separate service from the SMTP server.  As such, it is an authenticated 
service just as the IMAP service is.

Such servers are not in the DMZ, unless being in the DMZ is a requirement 
to make outgoing SMTP connections.

Of course, if you wish to allow submissions from outside, then it would 
have to be in the DMZ.  However, this is pretty useless unless you also 
allow IMAP access from outside.  In which case you don't really have a 
DMZ.  So, for the purpose of discussion a DMZ type environment, this 
doesn't apply.

Whether the SUBMIT server shares authentication credentials with the IMAP 
server, or has independent authentication credentials, is orthogonal.  
The key point to understand is that it does not impact Pull in either 
case.

The reason is URLAUTH.  URLAUTH restricts the access of the SUBMIT server 
to that data -- and only that data -- authorized by the sender of the 
message. There are additional value-added bells and whistles in URLAUTH so 
that, for example, the SUBMIT server may be required to authenticate 
itself as the SUBMIT server before it can use URLAUTH credentials.

In Pull, there is no need for the IMAP server to have any credentials on 
the SUBMIT server.  Nor is there a need for the SUBMIT server to have 
per-user credentials on the IMAP server (it *may* have credentials to 
prove that it's the SUBMIT server as value-added paranoia).

Push, on the other hand, presumes an authentication model in which either 
the SUBMIT server trusts the IMAP server completely, or the SUBMIT server 
is passed the credentials from the IMAP server.

As for your question as to which is better, an IMAP proxy or an SMTP 
proxy. Both are evil and fiendishly difficult to get right.  However, 
having written both, an SMTP proxy is much simpler than an IMAP proxy.

Finally, your comment about being required to use VPN or SSL/TLS to send 
mail from the IETF is what I'm talking about.  For people like me, this is 
nothing new.  For a few years now, I can not submit without authenticating 
to the SUBMIT server first, and unless I have Kerberos credentials I can't 
authenticate to the SUBMIT server without negotiating TLS with it first.

We still have a path in which clients from "good IP addresses" are allowed 
to submit without authentication.  That path periodically causes our 
outgoing mailers (which are different from the SUBMIT servers) to get 
listed in various RBLs.  Thanks to virus authors and spammers, 
non-authenticated submission from "trusted" addresses is on its way out.

-- Mark --