12:10 p.m.
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.
12:29 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:10 p.m.
Howard Chu <hyc(a)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?
7:33 a.m.
On 03/11/12 22:10 +0100, Daniel Pocock wrote:
Howard Chu <hyc(a)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.
--
Dan White
1:01 p.m.
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
11:47 a.m.
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.
5:41 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3008
days inactive
4216
days old
openldap-technical@openldap.org
6 comments
5 participants
participants (5)
-
Dan White -
Daniel Pocock -
Dimitri -
Howard Chu -
Michael Ströder