Excellent catch. This looks like a bug; as you might've guessed, we
don't yet use client side authentication with STARTTLS, and this code
was only tested a few times when it was first inserted.
I'll apply the patch you suggest.
The dn mapping is an open problem across multiple protocols and
authorization modules and it's a good question what to do here and the
easiest way to configure it. Doing it right may involve an LDAP query
to map dn to username.
Thanks,
Larry
Date: Thu, 15 Mar 2001 16:17:21 +0100
From: Norbert Klasen <[EMAIL PROTECTED]>
Organization: DFN Directory Services, ZDV Uni Tübingen
Hi,
if imtest is called with a client certificate (and the local ca cert has
been specified with tls_ca_file in /etc/imapd.conf) the imapd_userid
variable is set cmd_starttls() to external.auth_id, which is set in
tls_start_servertls to the CN part of the subject in the client cert.
From the logfile it appears as if the user is now authenticated:
imapd[26078]: starttls: TLSv1 with cipher DES-CBC3-SHA (168/168 bits)
authenticated as peerCN
However, since imapd_authstate does not get set, the user still has no
more rights than anonymous. Furthermore any attempts to AUTHENTICATE
fail with "BAD Already authenticated" because cmdloop() asserts that
imapd_userid is NOT set.
If the assignment to imapd_userid is removed, SASL EXTERNAL works:
--- imapd.c.orig Thu Mar 15 15:47:15 2001
+++ imapd.c Thu Mar 15 15:56:28 2001
@@ -4095,11 +4095,6 @@
fatal("sasl_setprop() failed: cmd_starttls()", EC_TEMPFAIL);
}
- /* if authenticated set that */
- if (external.auth_id != NULL) {
- imapd_userid = external.auth_id;
- }
-
/* tell the prot layer about our new layers */
prot_settls(imapd_in, tls_conn);
prot_settls(imapd_out, tls_conn);
> imtest -t mycert.pem -u "" -m EXTERNAL server
C: C01 CAPABILITY
S: * OK server Cyrus IMAP4 v2.0.12 server ready
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID
NO_ATOMIC_RENAME UNSELECT MULTIAPPEND SORT THREAD=ORDEREDSUBJECT
THREAD=REFERENCES IDLE STARTTLS AUTH=GSSAPI X-NETSCAPE
S: C01 OK Completed
S01 OK Begin TLS negotiation now
verify error:num=19:self signed certificate in certificate chain
TLS connection established: TLSv1 with cipher DES-CBC3-SHA (168/168
bits)
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID
NO_ATOMIC_RENAME UNSELECT MULTIAPPEND SORT THREAD=ORDEREDSUBJECT
THREAD=REFERENCES IDLE STARTTLS AUTH=LOGIN AUTH=PLAIN AUTH=GSSAPI
AUTH=EXTERNAL X-NETSCAPE
S: C01 OK Completed
C: A01 AUTHENTICATE EXTERNAL
S: +
C:
S: A01 OK Success (tls protection)
Authenticated.
Security strength factor: 0
1 select inbox
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
[..]
This requires that the CN in the cert is a valid imapd_userid and that
the authorization id is empty. A non empty authorization id does not
work; even if its the same as the CN.
The right thing to do would probably be to set external.auth_id to the
client's cert full subject DN and let the EXTERNAL mechanism handle the
mapping/proxying to an authorization id (by means of admin policy,
regexp or directory lookup).
