Mapping users (either KerberosV or TLS certs)
info-cyrus-spodhuis at spodhuis.org
Thu Jul 6 09:06:44 EDT 2006
On 2006-07-06 at 12:58 +0100, Dennis Davis wrote:
> Can't answer any of your questions, which I've deleted.
> I can't find a "keytab" option in the imapd.conf manual page.
> There's a srvtab option, but that applies to Kerberos4 which you
> aren't using.
Indeed. All my Kerberos _normal_ access works fine, and I (think I)
noted, that was just remnant cruft which I'm leaving in.
> > tls_cipher_list: ALL:!ADH:!EXP:+HIGH:+MEDIUM:!SSLv2:@STRENGTH
> I use:
> # Insist on "proper", rather than "mickey-mouse", ciphers. We'll
> # expect to see high (key length > 128 bits) or medium (key length
> # of 128 bits) ciphers, sorted by strength.
> tls_cipher_list: HIGH:MEDIUM:@STRENGTH
> Is there a reason I'm probably missing for the "!SSLv2" ?
I don't need to support large numbers of users, it's for me, so I can
safely skip the old ones. By disabling the cryptographically flawed
protocol, I get a hint if a client is configured to use only SSLv2, so I
can go kick it.
I also happen to think that the backwards-compatibility protocol stuff
to work with SSLv2 is ugly and grotesque and, whilst it works and is
perhaps a neat hack, I just dislike the idea of such hacks being in a
critical code path. So I knock it out, to get the new protocol which is
more easily extensible (without encoding data in padding).
I also believe that disabling something flawed is better than relying
upon crufty start-up-compatibility-contortions to protect against
> example pointing pine at my experimental IMAP server I usually see:
> Jul 6 12:48:32 bahamontes imap: starttls: TLSv1 with cipher AES256-SHA (256/256 bits new) no authentication
> Jul 6 12:48:32 bahamontes imap: login: hinault.bath.ac.uk [18.104.22.168] ccsdhd GSSAPI+TLS User logged in
For protocols, that's what I see too. :^) Now, if I could let
xxx/admin be treated as a Cyrus admin so I could proxy auth, as I can
with DIGEST-MD5, I'd be happier.
> See above. I'm fairly sure there's no "keytab" option. However you
> can set "sasl_keytab" to indicate where your Kerberos5 keytab lives:
> So my configuration reads:
My actual config has comments in it, which I grep'd out for the email.
The comments noted the use of the env method.
Okay, how come sasl_keytab works? I thought that sasl_foo in imapd.conf
was directly equivalent to foo in /usr/lib/sasl2/Cyrus.conf, where I had
tried a keytab directive and it doesn't work. My understanding was that
GSSAPI doesn't expose an API for SASL to tell it the keytab location.
Since I'm obviously wrong, can someone please explain what's actually
going on here?
"Everything has three factors: politics, money, and the right way to do it.
In that order." -- Gary Donahue
More information about the Info-cyrus