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: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 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.

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 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, 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.

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.