Closed Bug 28200 Opened 25 years ago Closed 19 years ago

Want SASL/Kerberos for IMAP Mail

Categories

(MailNews Core :: Security, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 303160

People

(Reporter: scootermorris, Assigned: tmartin)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

See bug # 17578 in Browser -- I would also like to be able to authenticate using 
Kerberos in Mail.  IMAP supports this in the protocol and (I believe) both UW 
IMAP and Cyrus provide implementations through SASL.
cc: phil
Sure, that's a good idea, but Netscape probably get to SASL or Kerberos for the 
next version. Adding to the helpwanted list.
Assignee: jefft → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
..."probably WON'T get to"...
Summary: Want Kerberos for IMAP Mail → Want SASL/Kerberos for IMAP Mail
Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.
Component: Security → Security: General
I have done some initial work on making use of the Cyrus SASL authentication
library with mozilla. Unfortunatly because of lack of COM knowledge I have
gotten stuck with a do_CreateInstance() always failing. The authentication
worked before I tried mozillifying the patches. I'm sure someone more familiar
with the mozilla code could fix this up fairly quickly.

Patch can be found at:
http://www.contrib.andrew.cmu.edu/~tmartin/mozilla-sasl-diffs.diff

After this hurdle is overcome I can help with any additional SASL work that
needs to be done. In particular the patches only do IMAP authentication (POP and
SMPT AUTH need to be added)
tmartin, that's great news! Thanks for volunteering for this!

I'm going to reassign this bug to you if you don't mind.

In order to get help, you should ask on
news://news.mozilla.org/netscape.public.mozilla.mail-news. There are a number of
folks who could help who hang out on that newsgroup.
Assignee: nobody → tmartin
Status: NEW → ASSIGNED
do you know what the error is coming back from trying to create the SASL object?
It's possible that
a) you haven't implemented QueryInterface correctly
b) the factory for the object isn't being registered

one thing you might be interested in is "xpcshell" - it's an XPConnect-aware JS 
shell - I use it for basic testing, and it will throw a JS exception telling you 
exactly what the failure is... it uses the same JS semantics as any JS that you 
can find in mozilla (i.e. var obj = 
Components.classes["some.progid"].createInstance...etc)

Bug 17048 concerning ACAP support in Mozilla would also benefit from SASL.
Blocks: 31766
Looks like a dupe of bug 17578
Not a dup of 17578.  That bug is about Kerberos under TLS in HTTP.
this bug is about Kerberos authentication in the SASL framework, which is needed
to support using kerberos against IMAP, LDAP, POP, SMTP, etc.

bug 17578 is about Kerberos in TLS, which could be used for HTTP authentication.
HTTP does not support SASL.

these are seperate issues.
Should SMTP also support Kerberos?
Should bug 70676 (Kerberize POP) be combined with this one? It seems if we're
going to do one, the solution should allow for both. And yes, we should
Kerberize SMTP. 
(In reply to comment #5)
> Patch can be found at:
> http://www.contrib.andrew.cmu.edu/~tmartin/mozilla-sasl-diffs.diff

Luckily, the URL is still valid. Attaching the patch here in bugzilla
nevertheless, to be safe.

tmartin, are you still around and interested? I could help you getting the
Mozilla-specific part solved.
Product: MailNews → Core
Blocks: 274929
The GSSAPI support added for the negotiateauth feature will not work for IMAP
and SMTP authentication.  The IETF standard for auth in these situations is to
use SASL with GSSAPI.   There are  plenty of SASL implementations available,
Cyrus SASL is freely available on most Linux distros, Solaris 10 has a native
SASL library (based on Cyrus) and I think even Microsoft has SASL support.  

Adding SASL-GSSAPI would extend the single-sign on capabilities of the Mozilla
suite to mail clients which is highly desirable in security conscious enterprises.

The patch referened above (comment 14) looks like a good starting point and
should be pursued to see if it is correct.


*** Bug 240778 has been marked as a duplicate of this bug. ***
See 240778 comment 1 and 2 (by bienvenu and darin)
Sorry, bug 240778 comment 1 (for linking)
One thing I just noticed is that there is no security layer
(integrity/privacy) support in that patch.  So it does not take full
advantage of sec. mechs. like GSSAPI that support a security layer.
Obviously, security layer support would be good to have with IMAP.
(In reply to comment #19)
> One thing I just noticed is that there is no security layer
> (integrity/privacy) support in that patch.  So it does not take full
> advantage of sec. mechs. like GSSAPI that support a security layer.
> Obviously, security layer support would be good to have with IMAP.

But not strictly necessary assuming STARTTLS; Simply being able to authenticate would be nice.
(In reply to comment #20)
> But not strictly necessary assuming STARTTLS; Simply being able to
authenticate would be nice.


Simply authenticating is already possible, it's just not secure.  I don't 
see the point of adding another authentication method if its not going to be 
secured properly.   If this effort is going to attempt to add proper SASL 
support, then it should be complete.
(In reply to comment #21)
> (In reply to comment #20)
> > But not strictly necessary assuming STARTTLS; Simply being able to
> authenticate would be nice.
> 
> 
> Simply authenticating is already possible, it's just not secure.  I don't 
> see the point of adding another authentication method if its not going to be 
> secured properly.   If this effort is going to attempt to add proper SASL 
> support, then it should be complete.

At a site using Kerberos I can't authenticate unless I send my password to the
other side. Well, either STARTTLS is secure, in which case, you have no problem,
and there's nothing to preclude implementing only authentication, or STARTTLS is
not secure, in which case allowing someone to type a password is irresponsible.
Pick one. I don't care which. 

I'm not saying supporting SASL security is bad. I'm saying not supporting GSSAPI
for authentication in the meantime (if Tim's patch is complete, anyway) is poor.
Authenticating with Kerberos credentials is not currently possible.  The
proposed patch claims to make this possible.  SASL/Kerberos is secure against
replay.  When used in conjunction with SSL or STARTTLS, it is secure against
eavesdropping and session hijacking.

If someone feels it is important to have SASL security layer support, then they
should create a patch to implement it.
Actually a naive combination of kerberos/gssapi authentication and channel
encryption (tls) is not secure against MITM attacks. Server authentication via
X.509 can help, but it is better to do things like the SSH protocol does for
GSSAPI - binding the authentication exchange to values that both sides derive
from the channel setup.

IIRC there are Kerberized cipher suites for TLS, they may be of help here.
Darin, I could have sworn we talked about this...Is this where we'd want to get
access to the kerberos code from?

http://lxr.mozilla.org/seamonkey/source/extensions/negotiateauth/nsHttpNegotiateAuth.cpp#44
(In reply to comment #25)
> Darin, I could have sworn we talked about this...Is this where we'd want to get
> access to the kerberos code from?
> 
>
http://lxr.mozilla.org/seamonkey/source/extensions/negotiateauth/nsHttpNegotiateAuth.cpp#44

No, that would be the wrong place to look.  The above code is for use with HTTP
authentication.   For IMAP we want to use the SASL for authentication.  SASL
then can use GSSAPI-KRB5 or GSSAPI-SPNEGO to perform the Kerberos ticket
exchanges.   
(In reply to comment #26)
> (In reply to comment #25)
> > Darin, I could have sworn we talked about this...Is this where we'd want to get
> > access to the kerberos code from?
> > 
> >
>
http://lxr.mozilla.org/seamonkey/source/extensions/negotiateauth/nsHttpNegotiateAuth.cpp#44
> 
> No, that would be the wrong place to look.  The above code is for use with HTTP
> authentication.   For IMAP we want to use the SASL for authentication.  SASL
> then can use GSSAPI-KRB5 or GSSAPI-SPNEGO to perform the Kerberos ticket
> exchanges.   

(In reply to comment #26)
> (In reply to comment #25)
> > Darin, I could have sworn we talked about this...Is this where we'd want to get
> > access to the kerberos code from?
> > 
> >
>
http://lxr.mozilla.org/seamonkey/source/extensions/negotiateauth/nsHttpNegotiateAuth.cpp#44
> 
> No, that would be the wrong place to look.  The above code is for use with HTTP
> authentication.   For IMAP we want to use the SASL for authentication.  SASL
> then can use GSSAPI-KRB5 or GSSAPI-SPNEGO to perform the Kerberos ticket
> exchanges.   

It doesn't implement SASL so its not appropriate for this bug (I think everyone
 is assuming if we linked against the OS's sasl implementation we would probably
get kerberos and and other security protocols for free) but the mentioned code
is a good place for generic GSSAPI Kerberos support so it might be more
appropriate for KPOP (bug 70676). 
Bug #303160 implements Kerberos support for POP, IMAP and SMTP using
SASL/GSSAPI. It doesn't use the Cyrus SASL library, but instead leverages the
negotiate auth code to implement the GSSAPI SASL mechanism.
marking dup.

*** This bug has been marked as a duplicate of 303160 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: