Want SASL/Kerberos for IMAP Mail

RESOLVED DUPLICATE of bug 303160

Status

MailNews Core
Security
P3
enhancement
RESOLVED DUPLICATE of bug 303160
18 years ago
10 years ago

People

(Reporter: Scooter Morris, Assigned: tmartin)

Tracking

({helpwanted})

Trunk
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.

Comment 1

18 years ago
cc: phil

Comment 2

18 years ago
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

Comment 3

18 years ago
..."probably WON'T get to"...

Updated

18 years ago
Summary: Want Kerberos for IMAP Mail → Want SASL/Kerberos for IMAP Mail

Comment 4

18 years ago
Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.
Component: Security → Security: General
(Assignee)

Comment 5

18 years ago
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)

Comment 6

18 years ago
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
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 7

18 years ago
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)

Comment 8

18 years ago
Bug 17048 concerning ACAP support in Mozilla would also benefit from SASL.

Updated

18 years ago
Blocks: 31766

Comment 9

16 years ago
Looks like a dupe of bug 17578

Comment 10

16 years ago
Not a dup of 17578.  That bug is about Kerberos under TLS in HTTP.

Comment 11

16 years ago
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. 

Comment 14

14 years ago
Created attachment 161255 [details] [diff] [review]
tmartin's patch (comment 5)

(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

Updated

14 years ago
Blocks: 274929

Comment 15

13 years ago
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.


Comment 16

13 years ago
*** Bug 240778 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
See 240778 comment 1 and 2 (by bienvenu and darin)

Comment 18

13 years ago
Sorry, bug 240778 comment 1 (for linking)

Comment 19

13 years ago
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.

Comment 20

13 years ago
(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.

Comment 21

13 years ago
(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.

Comment 22

13 years ago
(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.

Comment 23

13 years ago
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.

Comment 24

13 years ago
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.

Comment 25

13 years ago
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

Comment 26

13 years ago
(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). 

Comment 28

13 years ago
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.

Comment 29

13 years ago
marking dup.

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