Password-attached OTP for LDAP auth: possible w/ NMAS?


Hi there,

I need an LDAP server capable of authenticating used password-attached
OTP using OATH HOTP algorithm ('HOTP - Wikipedia, the free encyclopedia'
(http://en.wikipedia.org/wiki/HOTP)) as described in 'RFC 4226 - HOTP:
An HMAC-Based One-Time Password Algorithm'
(http://tools.ietf.org/html/rfc4226). The solution must be implemented
directly in the directory server to eliminate the need to have
additional cluster of OTP servers because in fact there are no reasons
to have separate OTP server, there are only reasons not to have it (it
makes the whole solution too complicated a brings unacceptable
additional risks because the OTP cluster needs to sepearately solve many
tasks that are already solved in the directory cluster, e.g. replication
and HA).

The idea seems quite simple to implement, the only change needed to do
this is to extend the password-checking logic to split the received
password with attachet OTP of fixed length to the password and OTP and
separately check each of these.

The best solution would most probably be to have the build-in NMAS
password-checking method (0x7) support password attached OTP (all that's
needed to do this is to have two additional per-user attributes
containing the shared secret and sequence counter, a few other
container-level attributes for common settings (OTP length, look-ahead
synchronization window size), and a little code that will split the OTP
from the password, check it and update the counter on success.
Unfortunatelly there seems to be no support for this in current versions
of eDirectory and there's no indicaton that this support is to be added
in future versions.

I've investigated the possibility of adding password attached OTP
support to eDirectory using NMAS, but so far it seems to be impossible,
because the LDAP auth seems to be an NMAS client supporting only NMAS
methods 0x7 (the NMAS method to check a password called NDS for some
reason) and 0x0 (unable to find out what's that), while there's no way
to make a LSM supporting these methods - an LSM with method ID 0x0
cannot be installed, while an LSM providing method ID 0x7 seems to
override everything but the method's code (installing such an LSM can
change method description, vendor, grade and other properties, but the
original code - LSM00000007 from libnmas.so - is still in use, LSM's
LSM00000007 is never called). Overriding the default password-checking
method also seems to be quite a bad idea considering that one would
either have to reimplement all its undocumeted features (password
expiration, intruder detection) or replace them with much simpler
password checking implementaton.

Is there some way to make the LDAP NMAS client support other methods
than 0x7?

And if the answer is yes, is it possible to call other login methods
from a module-provided login method (e.g. routing LDAP auth to method
LSM0000000x which wil just check the OTP checking, store the password
without OTP using MAF_PutAttribute(mh, NMAS_AID_PASSWORD, ...) and then
call original LSM00000007 to check the password)?

Or if the answer is no, is there some other way to make eDirectory
support OATH HOTP for LDAP authentication without the need to have a
separate OTP server?


--
vblaha
------------------------------------------------------------------------
vblaha's Profile: http://forums.novell.com/member.php?userid=69207
View this thread: http://forums.novell.com/showthread.php?t=403674

Tags:

  • I think it is possible, but I have not done it.

    Some resources you might check:
    Developing an NMAS Method
    http://www.novell.com/coolsolutions/feature/16005.html

    NMAS SDK
    http://developer.novell.com/wiki/index.php/Novell_Modular_Authentication_Service

    NMAS DOCs
    http://developer.novell.com/documentation/nmas/index.html


    -jim

    On 3/4/2010 6:56 AM, vblaha wrote:
    >
    > Hi there,
    >
    > I need an LDAP server capable of authenticating used password-attached
    > OTP using OATH HOTP algorithm ('HOTP - Wikipedia, the free encyclopedia'
    > (http://en.wikipedia.org/wiki/HOTP)) as described in 'RFC 4226 - HOTP:
    > An HMAC-Based One-Time Password Algorithm'
    > (http://tools.ietf.org/html/rfc4226). The solution must be implemented
    > directly in the directory server to eliminate the need to have
    > additional cluster of OTP servers because in fact there are no reasons
    > to have separate OTP server, there are only reasons not to have it (it
    > makes the whole solution too complicated a brings unacceptable
    > additional risks because the OTP cluster needs to sepearately solve many
    > tasks that are already solved in the directory cluster, e.g. replication
    > and HA).
    >
    > The idea seems quite simple to implement, the only change needed to do
    > this is to extend the password-checking logic to split the received
    > password with attachet OTP of fixed length to the password and OTP and
    > separately check each of these.
    >
    > The best solution would most probably be to have the build-in NMAS
    > password-checking method (0x7) support password attached OTP (all that's
    > needed to do this is to have two additional per-user attributes
    > containing the shared secret and sequence counter, a few other
    > container-level attributes for common settings (OTP length, look-ahead
    > synchronization window size), and a little code that will split the OTP
    > from the password, check it and update the counter on success.
    > Unfortunatelly there seems to be no support for this in current versions
    > of eDirectory and there's no indicaton that this support is to be added
    > in future versions.
    >
    > I've investigated the possibility of adding password attached OTP
    > support to eDirectory using NMAS, but so far it seems to be impossible,
    > because the LDAP auth seems to be an NMAS client supporting only NMAS
    > methods 0x7 (the NMAS method to check a password called NDS for some
    > reason) and 0x0 (unable to find out what's that), while there's no way
    > to make a LSM supporting these methods - an LSM with method ID 0x0
    > cannot be installed, while an LSM providing method ID 0x7 seems to
    > override everything but the method's code (installing such an LSM can
    > change method description, vendor, grade and other properties, but the
    > original code - LSM00000007 from libnmas.so - is still in use, LSM's
    > LSM00000007 is never called). Overriding the default password-checking
    > method also seems to be quite a bad idea considering that one would
    > either have to reimplement all its undocumeted features (password
    > expiration, intruder detection) or replace them with much simpler
    > password checking implementaton.
    >
    > Is there some way to make the LDAP NMAS client support other methods
    > than 0x7?
    >
    > And if the answer is yes, is it possible to call other login methods
    > from a module-provided login method (e.g. routing LDAP auth to method
    > LSM0000000x which wil just check the OTP checking, store the password
    > without OTP using MAF_PutAttribute(mh, NMAS_AID_PASSWORD, ...) and then
    > call original LSM00000007 to check the password)?
    >
    > Or if the answer is no, is there some other way to make eDirectory
    > support OATH HOTP for LDAP authentication without the need to have a
    > separate OTP server?
    >
    >


  • Thanks for links, I've already read them all but they don't give me an
    answer. I've also found a lot of maybe even more useful
  • Glad to know "my" wiki was helpful. ;)

    I am anxious what you can work out.

    Perhaps we should move this to the NMAS forum.
    Although AB is usually around here to.

    Maybe he can get some NMAS engineers to comment?

    Thanks
    -jim

    On 3/4/2010 9:56 AM, vblaha wrote:
    >
    > Thanks for links, I've already read them all but they don't give me an
    > answer. I've also found a lot of maybe even more useful

  • So far it seems no NMAS engineers around here... Where can I find the
    NMAS forum you mentioned? I don't see DEV: NMAS, but if there's a better
    place for this discussion, I definitely agree with moving the discussion
    there.

    Jim Willeke;1941864 Wrote:
    > Glad to know "my" wiki was helpful. ;)
    >
    > I am anxious what you can work out.
    >
    > Perhaps we should move this to the NMAS forum.
    > Although AB is usually around here to.
    >
    > Maybe he can get some NMAS engineers to comment?
    >
    > Thanks
    > -jim



    --
    vblaha
    ------------------------------------------------------------------------
    vblaha's Profile: http://forums.novell.com/member.php?userid=69207
    View this thread: http://forums.novell.com/showthread.php?t=403674

  • novell.support.modular-authentication-services

    -jim

    On 3/10/2010 5:36 AM, vblaha wrote:
    >
    > So far it seems no NMAS engineers around here... Where can I find the
    > NMAS forum you mentioned? I don't see DEV: NMAS, but if there's a better
    > place for this discussion, I definitely agree with moving the discussion
    > there.
    >
    > Jim Willeke;1941864 Wrote:
    >> Glad to know "my" wiki was helpful. ;)
    >>
    >> I am anxious what you can work out.
    >>
    >> Perhaps we should move this to the NMAS forum.
    >> Although AB is usually around here to.
    >>
    >> Maybe he can get some NMAS engineers to comment?
    >>
    >> Thanks
    >> -jim

    >
    >