[Dovecot] [patch] gssapi support
Hi,
I've been working on a patch for GSSAPI (Kerberos) support. It seems to work pretty well for authentication (I've tested it with Evolution, fetchmail, and mutt). I have also been working on implementing integrity/confidentiality protection. Unfortunately not many clients support this - the only one I've found really is mutt, which seems to disconnect from the server for some unknown reason not long after a Kerberos-secured conversation. I'm still trying to track that down.
But anyways the patch is far along enough that I think it's worthy of review and testing.
Some todo items:
- Track down bug preventing mutt from working
- Audit integrity proxy a bit more
- Make sure we're handling mechanisms other than Kerberos
- Test with more clients
On Mon, 2004-07-12 at 17:20, Colin Walters wrote:
I've been working on a patch for GSSAPI (Kerberos) support. It seems to work pretty well for authentication (I've tested it with Evolution, fetchmail, and mutt). I have also been working on implementing integrity/confidentiality protection. Unfortunately not many clients support this - the only one I've found really is mutt, which seems to disconnect from the server for some unknown reason not long after a Kerberos-secured conversation. I'm still trying to track that down.
But anyways the patch is far along enough that I think it's worthy of review and testing.
Thanks, I took a quick look through and it looked good. Integrity proxy should perhaps be moved into lib-auth in case it gets useful for other things than login process.
On Mon, 2004-07-12 at 17:49 +0300, Timo Sirainen wrote:
On Mon, 2004-07-12 at 17:20, Colin Walters wrote:
I've been working on a patch for GSSAPI (Kerberos) support. It seems to work pretty well for authentication (I've tested it with Evolution, fetchmail, and mutt). I have also been working on implementing integrity/confidentiality protection. Unfortunately not many clients support this - the only one I've found really is mutt, which seems to disconnect from the server for some unknown reason not long after a Kerberos-secured conversation. I'm still trying to track that down.
But anyways the patch is far along enough that I think it's worthy of review and testing.
Thanks, I took a quick look through and it looked good.
Cool, thanks. I'd like to have it actually working with mutt before it goes in, but if you don't see any architectural problems, that's encouraging.
Integrity proxy should perhaps be moved into lib-auth in case it gets useful for other things than login process.
Hm. I was modeling the integrity support after the SSL support, since conceptually it's very similar. I'm not sure which other process would use the integrity support? Both POP3 and IMAP define integrity and confidentiality as starting after authentication, so it would only come into play after the auth process was used. I don't see how master would use it sensibly. I think it would be difficult to use from the imap process since that runs only with user privilege, and at least Kerberos requires access to the keytab file, which should not be readable by regular users.
On Mon, 2004-07-12 at 18:07, Colin Walters wrote:
Thanks, I took a quick look through and it looked good.
Cool, thanks. I'd like to have it actually working with mutt before it goes in, but if you don't see any architectural problems, that's encouraging.
I'm not sure when I'm actually going to put it in, it needs at least some small coding style changes. Consistency is good :) I'll warn you anyway before that so if you've done any changes they won't break then.
Integrity proxy should perhaps be moved into lib-auth in case it gets useful for other things than login process.
Hm. I was modeling the integrity support after the SSL support, since conceptually it's very similar. I'm not sure which other process would use the integrity support?
I was mostly thinking about things which don't exist yet. Such as there's already Postfix patch to authenticate from dovecot-auth, would it make sense to add integrity proxy to it?
On Mon, 2004-07-12 at 18:38 +0300, Timo Sirainen wrote:
On Mon, 2004-07-12 at 18:07, Colin Walters wrote:
Thanks, I took a quick look through and it looked good.
Cool, thanks. I'd like to have it actually working with mutt before it goes in, but if you don't see any architectural problems, that's encouraging.
I'm not sure when I'm actually going to put it in, it needs at least some small coding style changes. Consistency is good :) I'll warn you anyway before that so if you've done any changes they won't break then.
Ok :)
By the way I looked over the integrity proxy again, and I spotted the obvious stupid mistake in the length prefix marshalling :) Relative patch attached.
I can now confirm it works correctly with mutt.
Is there a more elegant way to do it? The buffer API doesn't have a way to reserve bytes, and I was worried about alignment issues with the cast-to-uint32_t approach.
I was mostly thinking about things which don't exist yet. Such as there's already Postfix patch to authenticate from dovecot-auth, would it make sense to add integrity proxy to it?
Ah...maybe. Postfix already has its own SASL implementation, so the Postfix patch could be extended to be able to receive an exported GSS context and do its own integrity/confidentiality protection in the smtpd process. I guess it would be possible to have dovecot-auth do the integrity protection proxying itself in the same way imap-login does now, but given that Postfix has its own SASL it probably makes more sense to give control back to that.
On Mon, 2004-07-12 at 18:49, Colin Walters wrote:
Is there a more elegant way to do it? The buffer API doesn't have a way to reserve bytes, and I was worried about alignment issues with the cast-to-uint32_t approach.
buffer_get_space_unsafe() and buffer_append_space_unsafe() maybe? Or I'd do it by first converting the integer to network byte order, then buffer_append(buf, &num, sizeof(num)). There's macros for that in lib/byteorder.h.
I was mostly thinking about things which don't exist yet. Such as there's already Postfix patch to authenticate from dovecot-auth, would it make sense to add integrity proxy to it?
Ah...maybe. Postfix already has its own SASL implementation, so the Postfix patch could be extended to be able to receive an exported GSS context and do its own integrity/confidentiality protection in the smtpd process. I guess it would be possible to have dovecot-auth do the integrity protection proxying itself in the same way imap-login does now, but given that Postfix has its own SASL it probably makes more sense to give control back to that.
Postfix uses Cyrus SASL library to do all the SASL stuff (well, except parsing the SMTP commands of course). I replaced that completely with my patch (http://dovecot.org/patches/postfix/).
Anyway, Postfix didn't do integrity protection with Cyrus library either even though it supported it. Also I was thinking about modifying my patch some day to use only Postfix's internal functions since all it really needs is some simple UNIX socket talking. So I guess integrity proxy might as well be in login-common.
On Mon, 2004-07-12 at 19:04 +0300, Timo Sirainen wrote:
Or I'd do it by first converting the integer to network byte order, then buffer_append(buf, &num, sizeof(num)). There's macros for that in lib/byteorder.h.
Done, thanks.
Postfix uses Cyrus SASL library to do all the SASL stuff (well, except parsing the SMTP commands of course). I replaced that completely with my patch (http://dovecot.org/patches/postfix/).
I see.
Anyway, Postfix didn't do integrity protection with Cyrus library either even though it supported it.
Hm, that's too bad. Kerberos support isn't useful to me unless it does integrity, since otherwise you need SSL, and I'm trying to avoid using SSL.
Also I was thinking about modifying my patch some day to use only Postfix's internal functions since all it really needs is some simple UNIX socket talking.
That would probably be necessary if the patch is going to be upstreamed, I imagine.
So I guess integrity proxy might as well be in login-common.
Ok.
Colin Walters wrote:
On Mon, 2004-07-12 at 19:04 +0300, Timo Sirainen wrote:
Anyway, Postfix didn't do integrity protection with Cyrus library either even though it supported it.
Hm, that's too bad. Kerberos support isn't useful to me unless it does integrity, since otherwise you need SSL, and I'm trying to avoid using SSL.
Why? Is SSL bad in some way?
(not a trick question - I simply feel I might learn something from this)
- Jonas
--
Jonas Smedegaard - idealist og Internet-arkitekt
Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
On Tue, Jul 13, 2004 at 01:02:14AM +0200, Jonas Smedegaard wrote:
Hm, that's too bad. Kerberos support isn't useful to me unless it does integrity, since otherwise you need SSL, and I'm trying to avoid using SSL.
Why? Is SSL bad in some way?
At the very least, it adds complexity, and an overhead in the public-key cryptography.
Kerberos already provides mutual authentication and, as a side effect of the authentication, a session key. If you're going to use SSL as well, the SSL session key needs to be negotiated separately. RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) attemtps to address these issues, but I'm not sure how widely this is implemented.
-- Ray Miller, Unix Systems Programmer & Team Leader Systems Development & Support, Computing Services, University of Oxford
On Tue, 2004-07-13 at 01:02 +0200, Jonas Smedegaard wrote:
Colin Walters wrote:
On Mon, 2004-07-12 at 19:04 +0300, Timo Sirainen wrote:
Anyway, Postfix didn't do integrity protection with Cyrus library either even though it supported it.
Hm, that's too bad. Kerberos support isn't useful to me unless it does integrity, since otherwise you need SSL, and I'm trying to avoid using SSL.
Why? Is SSL bad in some way?
SSL isn't bad. The situation is this: I am setting up a new server (email/web,etc) for myself, a few friends, and my dad. The first time I did this, I created my own CA, and used my own certificates for imap and smtp, because I didn't want to pay a thousand dollars (i.e. about as much as my hardware cost) to Verisign. The major problem I ran into was getting my dad and some of my friend's Windows machines to trust my CA. It involved a lot of complexity with this "mmc" program. Not to mention my dad has multiple machines, one of them at his office that I didn't have access to. The rest of my friends use Linux as I do, but even there configuring different applications to trust a certificate isn't easy.
Kerberos seems rather ideal for this situation instead of certificates, since it doesn't require any client-side configuration or information except their password. So I'm working on using Kerberos this second time around.
As Ray pointed out Kerberos and SSL aren't exclusive, but normally when people say "SSL" they mean the certificate-based mechanisms.
There are other reasons to use Kerberos instead of SSL too:
http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbvsssl
On 13.7.2004, at 18:17, Colin Walters wrote:
The major problem I ran into was getting my dad and some of my friend's Windows machines to trust my CA. It involved a lot of complexity with this "mmc" program. Not to mention my dad has multiple machines, one of them at his office that I didn't have access to. The rest of my friends use Linux as I do, but even there configuring different applications to trust a certificate isn't easy.
Adding new CAs is actually pretty easy in Windows. You right click it, "install certificate", place it into "Trusted root certificates" and click ok/next a few times.
I have no idea how to do it in Linux though. Does OpenSSL have some hardcoded root certificates directory, or does each program handle it in it's own way? Before Evolution used to ask me constantly about my certificate, and lazy as I were I just clicked "ok". Nowadays it seems to be silent, maybe one day it started remembering it.
On Tue, Jul 13, 2004 at 07:04:09PM +0300, Timo Sirainen wrote:
I have no idea how to do it in Linux though. Does OpenSSL have some hardcoded root certificates directory, or does each program handle it in it's own way?
A bit of both: there is a system-wide certificate directory, but some applications also have their own certificate store. mutt, when linked agaisnt OpenSSL, allows a user to store CA certificates in a default location of ~/.mutt_certificates, and use of the system-wide certificate directory can be toggled. I'm not so familiar with other clients.
On a Debian system, you can "apt-get install ca-certificates" to populate the system directory.
-- Ray Miller, Unix Systems Programmer & Team Leader Systems Development & Support, Computing Services, University of Oxford
On Tue, 2004-07-13 at 19:04 +0300, Timo Sirainen wrote:
On 13.7.2004, at 18:17, Colin Walters wrote:
The major problem I ran into was getting my dad and some of my friend's Windows machines to trust my CA. It involved a lot of complexity with this "mmc" program. Not to mention my dad has multiple machines, one of them at his office that I didn't have access to. The rest of my friends use Linux as I do, but even there configuring different applications to trust a certificate isn't easy.
Adding new CAs is actually pretty easy in Windows. You right click it, "install certificate", place it into "Trusted root certificates" and click ok/next a few times.
I'll take your word for it. I had just searched the Microsoft site about the issue and found an article that told me to use mmc.
I have no idea how to do it in Linux though. Does OpenSSL have some hardcoded root certificates directory, or does each program handle it in it's own way?
Both :)
On my Fedora system all the root certificates are in /usr/share/ssl/certs/ca-bundle.crt.
But there is no standard way for an unprivileged user to write to that file.
Before Evolution used to ask me constantly about my certificate, and lazy as I were I just clicked "ok". Nowadays it seems to be silent, maybe one day it started remembering it.
I think Evolution remembers the result now, and keeps it around in its own certificate cache.
If it's really as easy to install root certificates on Windows as you say, then I might give it another try.
Colin Walters wrote:
On Mon, 2004-07-12 at 18:38 +0300, Timo Sirainen wrote:
I was mostly thinking about things which don't exist yet. Such as there's already Postfix patch to authenticate from dovecot-auth, would it make sense to add integrity proxy to it?
Ah...maybe. Postfix already has its own SASL implementation, so the Postfix patch could be extended to be able to receive an exported GSS context and do its own integrity/confidentiality protection in the smtpd process. I guess it would be possible to have dovecot-auth do the integrity protection proxying itself in the same way imap-login does now, but given that Postfix has its own SASL it probably makes more sense to give control back to that.
I guess you are talking about the unofficial TLS patch to postfix. It uses CYRUS SASL unwanted by some, so (small and easier to proofread) alternatives would probably be appreciated.
- Jonas
On Mon, 2004-07-12 at 19:04, Jonas Smedegaard wrote:
I guess you are talking about the unofficial TLS patch to postfix. It uses CYRUS SASL unwanted by some, so (small and easier to proofread) alternatives would probably be appreciated.
Actually at least Postfix 2.1.2 includes SASL without patching.
Timo Sirainen wrote:
On Mon, 2004-07-12 at 19:04, Jonas Smedegaard wrote:
I guess you are talking about the unofficial TLS patch to postfix. It uses CYRUS SASL unwanted by some, so (small and easier to proofread) alternatives would probably be appreciated.
Actually at least Postfix 2.1.2 includes SASL without patching.
I stand corrected. The SASL/TLS patch included in the Debian postfix package is an enhancement of code already existing in postfix. Sorry.
- Jonas
participants (4)
-
Colin Walters
-
Jonas Smedegaard
-
Ray Miller
-
Timo Sirainen