Some time ago I created the dynalogin ( http://www.dynalogin.org ) solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it convenient to use with OpenLDAP seems like a good strategy: can anyone comment on that?
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it could be adapted for SASL PLAIN or DIGEST-MD5)
- should not prevent password logins (user should be able to use either password or HOTP code)
- should enable people to use it indirectly (e.g. if someone already has pam_ldap working, they should be able to add dynalogin to their OpenLDAP server and get immediate benefit)
- use cases: UNIX login, high-security webmail login, VPN and OpenID provider backed by OpenLDAP
I know that SASL already supports OTP, but that is not HOTP, it is OPIE (or S/Key) RFC 2289: http://tools.ietf.org/html/rfc2289
whereas HOTP is RFC 4226: http://www.ietf.org/rfc/rfc4226.txt
HOTP is considered more secure and more widely implemented.
Daniel Pocock wrote:
Some time ago I created the dynalogin ( http://www.dynalogin.org ) solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it convenient to use with OpenLDAP seems like a good strategy: can anyone comment on that?
This is not the place to make that happen. LDAP uses SASL as its extensible authentication mechanism, you should be looking there.
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it
could be adapted for SASL PLAIN or DIGEST-MD5)
Yes, provide a Cyrus-SASL plugin implementing your mechanism and then it will immediately be usable in OpenLDAP and a number of other software packages.
- should not prevent password logins (user should be able to use either
password or HOTP code)
- should enable people to use it indirectly (e.g. if someone already has
pam_ldap working, they should be able to add dynalogin to their OpenLDAP server and get immediate benefit)
- use cases: UNIX login, high-security webmail login, VPN and OpenID
provider backed by OpenLDAP
I know that SASL already supports OTP, but that is not HOTP, it is OPIE (or S/Key) RFC 2289: http://tools.ietf.org/html/rfc2289
whereas HOTP is RFC 4226: http://www.ietf.org/rfc/rfc4226.txt
HOTP is considered more secure and more widely implemented.
Howard Chu hyc@symas.com wrote:
Daniel Pocock wrote:
Some time ago I created the dynalogin ( http://www.dynalogin.org ) solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making
it
convenient to use with OpenLDAP seems like a good strategy: can
anyone
comment on that?
This is not the place to make that happen. LDAP uses SASL as its extensible authentication mechanism, you should be looking there.
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it
could be adapted for SASL PLAIN or DIGEST-MD5)
Yes, provide a Cyrus-SASL plugin implementing your mechanism and then it will immediately be usable in OpenLDAP and a number of other software packages.
I'm familiar with SASL and how it is accessed with ldapsearch, etc
My reasons for raising the subject with OpenLDAP users are
- many other apps don't do SASL directly, they use an LDAP search or sometimes a bind to validate a log on, so I'm more likely to come across potential use cases here
- I'm curious about how useful the SASL plugin will be without modifying such apps, and any practical suggestions about how to support use cases that I may not have anticipated
- there seem to be some choices, e.g. I could just offer the PLAIN mechanism and the HOTP token is submitted as a password, or it could be offered as some other arbitrary mechanism - does that choice impact OpenLDAP users significantly?
On 03/11/12 22:10 +0100, Daniel Pocock wrote:
Howard Chu hyc@symas.com wrote:
Daniel Pocock wrote:
Some time ago I created the dynalogin ( http://www.dynalogin.org ) solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it convenient to use with OpenLDAP seems like a good strategy: can anyone comment on that?
Yes, provide a Cyrus-SASL plugin implementing your mechanism and then it will immediately be usable in OpenLDAP and a number of other software packages.
I'm familiar with SASL and how it is accessed with ldapsearch, etc
My reasons for raising the subject with OpenLDAP users are
- many other apps don't do SASL directly, they use an LDAP search or
sometimes a bind to validate a log on, so I'm more likely to come across potential use cases here
'log on' implies some kind of shell access, or scenario where pam is involved, which you already support. Although SASL is the more elegant solution, it's really on necessary where you're doing searching or direct LDAP connections between the client and the server (or where you want to reduce duplicated work where you're also authenticating, say, IMAP and SMTP connections).
- I'm curious about how useful the SASL plugin will be without modifying
such apps, and any practical suggestions about how to support use cases that I may not have anticipated
http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/components.php
- there seem to be some choices, e.g. I could just offer the PLAIN
mechanism and the HOTP token is submitted as a password, or it could be offered as some other arbitrary mechanism - does that choice impact OpenLDAP users significantly?
That's pretty much 'just a password'. PLAIN will not support two factor authentication. In that case, it would be easier to just run SASL PLAIN and pass-through authentication to saslauthd, with its pam backend.
Hi,
I've been working on a related problem recently, so this may sound interesting to you. I've developed a SLAPI plugin that implements OATH HOTP authentication as LDAP simple bind. Token objects are stored in LDAP directory; synchronization is implemented as an EXOP. SLAPI implementation in OpenLDAP lacked EXOP support, so I've fixed that, too (and I'm going to submit a patch soon). The project is being prepared to be published under an open license. If that sounds interesting for you, don't hesitate to drop me an email.
I'm also planning to port this plugin to OpenLDAP's native overlay API.
Dimitri
Dimitri,
Dimitri wrote:
I've been working on a related problem recently, so this may sound interesting to you. I've developed a SLAPI plugin that implements OATH HOTP authentication as LDAP simple bind. Token objects are stored in LDAP directory; synchronization is implemented as an EXOP. SLAPI implementation in OpenLDAP lacked EXOP support, so I've fixed that, too (and I'm going to submit a patch soon). The project is being prepared to be published under an open license. If that sounds interesting for you, don't hesitate to drop me an email.
I'm also planning to port this plugin to OpenLDAP's native overlay API.
I'm currently also working one something like that. I'd also like to have a standardized schema.
Did you have a chance to publish something of your stuff?
Ciao, Michael.
Michael Ströder wrote:
Dimitri,
Dimitri wrote:
I've been working on a related problem recently, so this may sound interesting to you. I've developed a SLAPI plugin that implements OATH HOTP authentication as LDAP simple bind. Token objects are stored in LDAP directory; synchronization is implemented as an EXOP. SLAPI implementation in OpenLDAP lacked EXOP support, so I've fixed that, too (and I'm going to submit a patch soon). The project is being prepared to be published under an open license. If that sounds interesting for you, don't hesitate to drop me an email.
I'm also planning to port this plugin to OpenLDAP's native overlay API.
I'm currently also working one something like that. I'd also like to have a standardized schema.
Fyi, I've been working on a TOTP overlay the past few days. (Overlay and pw crypt mechanism.) Should be showing up in git this week.
openldap-technical@openldap.org