[Dovecot] dovecot patch for TCB auth
Hi,
I'm writing to you on behalf of the Pasteur Institute's (Paris, France) IT team. We're currently using dovecot-0.99.10.5_2 on a FreeBSD 5.3. We're planning to upgrade to dovecot-1.x with an openLDAP user and password database and patch it at the same time to include some authentication feature we're using :
Since most of our user currently don't use dovecot at all and still authenticate on a DEC alpha running OSF1 [digital unix] V5.1 732, an authentication profile is maintained for each of them on the system. This user profile is kept in the protected password database, accessible only to trusted programs acting on behalf of the trusted computing base (TCB).
Some TCB fields are useful to us so we're planning to use their LDAP attibute equivalents and we wrote a custom LDAP shema that includes those which were missing from the standard openLDAP distribution [see details below].
So we're planning (in fact are about to) patch dovecot-1.x in order to take those LDAP attribute (matching the TCB field of interest to us) into account. To do so, we wrote some documentation (still in a draft state) to extend our understanding of dovecot architecture and authentication process.
Of course, we're going to give it (patch + doc) back to you and make it freely available. But we'd like to know if you :
were already working on such a patch or planning to do so
were interested, once done (by us or you) to include it into the official release, since it could interest some other person who runs digital unix with TCB authentication
Thanks
-- Thomas Hummel | Institut Pasteur, Paris, France <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
Here are some details about which attribute we're planning to use and their TCB equivalents
uidNumber ~ u_id uid ~ u_name userPassword ~ u_pwd shadowLastChange ~ u_succhg shadowExpire ~ u_expdate shadowMax ~ u_life shadowWarning ~ u_exp [ shadowWarning = u_life - u_exp]
plus the one we wrote :
maxTries ~ u_maxtries
[ maximum number of consecutive unsuccessful login attempts to the account that are permitted until the account is disabled ]
numUnsucLog ~ u_numunsuclog
[ number of unsuccessful login attempts to the account. It is reset when a successful login to the account occurs.]
Lock ~ u_lock
[ A boolean indicating if the account is locked ]
On 7.3.2005, at 12:49, Thomas Hummel wrote:
So we're planning (in fact are about to) patch dovecot-1.x in order to take those LDAP attribute (matching the TCB field of interest to us) into account. To do so, we wrote some documentation (still in a draft state) to extend our understanding of dovecot architecture and authentication process.
Of course, we're going to give it (patch + doc) back to you and make it freely available. But we'd like to know if you :
- were already working on such a patch or planning to do so
I wasn't, and I doubt anyone else was either.
- were interested, once done (by us or you) to include it into the official release, since it could interest some other person who runs digital unix with TCB authentication
I'm not sure if I understood this correctly. How does TCB and LDAP fit together? Does TCB simply provide LDAP view for its data? So is your patch only about handling the extra LDAP fields, or is it about providing some completely TCB-specific code (and LDAP being something else)?
In any case, if it's entirely TCB-specific I doubt I'd include it in the release, as there would be only a few users for it. I could put it in the web site though and add some pointers in documentation that there are other authentication plugins available as well.
On Tue, Mar 08, 2005 at 12:03:07AM +0200, Timo Sirainen wrote:
I'm not sure if I understood this correctly. How does TCB and LDAP fit together? Does TCB simply provide LDAP view for its data? So is your patch only about handling the extra LDAP fields, or is it about providing some completely TCB-specific code (and LDAP being something else)?
LDAP and TCB are two different things. We simply want to handle extra LDAP attribute (i.e. in addition of uid, homeDirectory, uidNumber, gidNumber and userPassword) because they are meant to provide the same extra (and valuable) authentication info that the TCB fields did (thus providing a way to know that, for instance, a user user agent has made 20 consecutive attempts to log in with an incorrect password and to lock it's account for that reason).
We'll let you know when we're done anyway.
Thanks.
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
participants (2)
-
Thomas Hummel
-
Timo Sirainen