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.

..."probably WON'T get to"...

Bulk moving all MailNews Security bugs to new Security: General component. The previous Security component for MailNews will be deleted.

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.

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.

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.

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 ***