Novell and MIT moving forward on LDAP Plugin

[Douglas E. Engert]

Here is an issue: One time passwords. How will these be handled in regard
to the database?

(1) Some KDC mods have the KDC store the base secret and the next expected
password and then generate the next N number of possible passwords trying
to decrypt with each, then update the database.

   Advantage:    All code is in the KDC.
   Disadvantage: A user's hardware tokens can only be used by Kerberos, and
                 only for this realm.


(2) Some KDC mods have the KDC request from a OTP server the next N passwords,
trying to decrypt with each, then send back to the server which one was used,
so the server can update its database.

   Advantage:    User's hardware tokens can be use for more then Kerberos
                 as the OPT server may support other authentication methods
                 such as RADIUS.
   Disadvantage: KDC must be completely trusted by OTP server.


(3) Another approach (I have not seen mods for this) is to have the KDC
send the pa-data to the OTP server to decrypt, and then the OTP server
updates its database and tells the KDC it was accepted.

   Advantage:    User's Hardware token can be used for more then Kerberos,
                 and the KDC and OPT servers don't have to belong to the
                 same organization. Could be used even if cross-realm
                 not setup across organizations.
   Disadvantage: Some of the Kerberos processing must be moved to OPT
                 server and it starts to look like (2). If cross-realm
                 is available between organizations then (2) looks
                 simpler.



Sam Hartman wrote:
> 
> Hi.
> 
> I wanted to update everyone on a conference call MIT and Novell had
> Tuesday evening.
> 
> 
> We believe that the best course of action going forward is for
> interested parties to write up the list of issues they would like to
> see improved in the LDAP plugin and then to get together and discuss
> who is doing the work.
> 
> We're hoping that people who bring forward issues also plan to commit
> time to helping solve issues.
> 
> Here's MIT's issue list:
> 
> Blocking issues:
> 
> 1) MIT needs to be able to test the LDAP plugin.  This means we need
> to be abel to set up LDAP realms and run some set of tests against
> them.  We believe that this is an internal MIT issue at this point: we
> just need to do the work to get a test environment that works better
> than what we have.
> 
> Non-blocking Issues:
> 
> 1) We would like to see the schema improved.  We would like to
>     separate out attributes from the secret key attribute.  In general
>     we only see a need to support one principal per ldap object, but
>     have links to other related objects.
> 
> 2) ldapi support
> 
> 3) Support for kdb5_util integration that supports dump load create
>     and destroy.
> 
> I'd appreciate if people could try and send in issue lists within the
> next few days.
> 
> --Sam
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444