Re: [Fed-Talk] MAPI vs IMAP Security Comparison Hunt
Re: [Fed-Talk] MAPI vs IMAP Security Comparison Hunt
- Subject: Re: [Fed-Talk] MAPI vs IMAP Security Comparison Hunt
- From: "Nascimento, Ronaldo M." <email@hidden>
- Date: Fri, 10 Oct 2008 12:29:18 -0400
- Thread-topic: [Fed-Talk] MAPI vs IMAP Security Comparison Hunt
Title: Re: [Fed-Talk] MAPI vs IMAP Security Comparison Hunt
Also, when you open up for Darwin, you also allow some options for other Unix distros too.
Evolution works great with IMAP.
On 10/10/08 8:23 AM, "Wm. Cerniuk" <email@hidden> wrote:
Tim,
Wow. That's a response.
I am not familiar with some of the MS technologies mentioned but you have definitely given me a foundation for research in those cases. Thank you, outstanding, I feel like I owe you a consulting fee :-)
I should note that our Microsoft friend on the list supplied a very detailed response as well but off channel due to the age of the thread.
For background, I endeavor to build a case for supporting IMAP on MS Exchange servers in our enterprise. I have talked to our Exchange savvy systems engineers and they have shown me that out of the box, the IMAP service is active. Even more interestingly, Microsoft has made activating this service trivial, a single checkbox! (a page from Apple's playbook) This would imply that MS sees this as core competency of the server software suite (correct me if I am wrong here). Further, I have heard from people who do not care for MS in any way, shape or form that the MS implementation of IMAP is actually quite robust.
So the treatment becomes:
- Benefits to Windows users
- Outlook users
- other email client users
- Benefits to Macintosh users
- Entourage users
- Mail users
- other email client users
- Benefits to Enterprise
- Long Haul Network Capable (not a LAN based protocol)
- Secure Internet Access to Mail Service
- Ubiquitous Mail Client / Operating System Platform Support
- As Secure as MAPI (more?)
- [what else?]
(not necessarily in that order)
and as I write this, it occurs to me that a white paper on the benefits of using MS Exchange's IMAP would be useful to more than just my endeavor...
But I may be wasting my time with the upcoming Snow Leopard?
Very Respectfully,
Wm. Cerniuk
E2E Project Manager, Innovation Program
Chief Health Informatics Office
VHA Office of Information
703.594.7616
Time is Short, and the Water Rises
On Oct 2, 2008, at 3:41 PM, Timothy J. Miller wrote:
Wm. Cerniuk wrote:
I am hunting for a white paper or otherwise that compares and contrasts the security of both IMAP and MAPI.
Authentication methods:
MAPI: LANMAN, NTLM, Kerberos.
IMAP: plaintext password, NTLM, MD5, GSSAPI (offers multiple methods, most commonly Kerberos), PKI.
Notes on authentication:
LANMAN is easily broken but should be disabled on systems run by people with a clue.
NTLM hashes are dangerous to use on the Internet given the new(ish) pass-the-hash attacks, and shouldn't be allowed for remote access to mail.
Kerberos requires connectivity to a KDC (a.k.a. AD DC), also typically not allowed for remote access users because of the sensitivity of the Kerberos key database.
MD5 is a password hash technique, and may be vulnerable to rainbow table attacks.
PKI provides mutual authentication between client and server, provides confidentiality, but requires specific support in the IMAP server. Not all IMAP servers support it. MAPI does not support PKI authentication.
Confidentiality methods:
MAPI: IPSec or SSL (only with RPC/HTTPS)
IMAP: IPSec or SSL.
Notes on confidentiality:
IPsec is a real beast, and generally overkill when protecting only a single protocol. If this is your option, better to provide full VPN connectivity instead. IPSec protection for both MAPI and IMAP cannot be leveraged for authentication to the mail service; i.e., if you have to authenticate for IPsec, you have to authenticate for MAPI/IMAP separately.
SSL for MAPI is only available using RPC/HTTPS as the MAPI transport. This is supported by MS, but does *not* support mutual authentication at the SSL layer. MAPI will still authenticate using LANMAN or NTLM in this case, using SSL only for confidentiality. These users will be generally restricted to using cached credentials as they will not have a KDC available.
IMAP/SSL (a.k.a. IMAPS) is built into most IMAP servers. IMAP with SSL can be used for mutual authentication, if the user has a certificate. This can be leveraged by the IMAP service--if the server supports it--to authenticate the user to his mailbox all in one go. Otherwise, IMAP will operate much like MAPI, using SSL for confidentiality only and transporting another, weaker, authentication inside that channel.
The practical upshot:
It depends on the use case. If you're talking about remote access to email (i.e., crossing the enclave boundary), IMAP is better IMHO. Support for confidentiality and strong authentication for remote users is much better and simpler to deploy. However, IMAP doesn't do calendaring with Exchange; only MAPI can do this. But that forces you into a weaker authentication model.
To put this into DoD context (this is fed-talk, right? :)--MAPI over RPC/HTTPS is strictly forbidden by JTF-GNO because it cannot comply with the PKI authentication requirements of CTOs 06-02 and 07-15.
-- Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Ronaldo Nascimento
IT Specialist, PVAMC
Facility Information Technology Service (FITS)
Office of Information & Technology (OI&T)
215-823-5259
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden