Heimdal compatibility

[Andrew Bartlett]

On Mon, 2006-08-07 at 12:13 -0400, Jeffrey Hutzelman wrote:
> 
> On Sunday, August 06, 2006 01:53:05 PM -0400 Sam Hartman <hartmans at mit.edu> 
> wrote:
> 
> > How do we balance these concerns against the equally valid desires to
> > minimize divergence and to allow people to reuse code where
> > appropriate.  I'm looking for options that MIt can implement
> > unilaterally.  I'd be delighted if we had more coordination with
> > Heimdal on issues like this, but I cannot depend on that being the
> > case.
> 
> I don't think there's anything you can do unilaterally that you'll like. 
> What you're talking about is basically maintaining a minimum level of 
> interoperability without tying your hands with regard to adding new 
> features in the future.  I can think of only three ways to get 
> interoperability.  The first two are coordination and luck.  The third 
> involves implementing everything the thing you want to be interoperable 
> with does, and being very sparing with adding new features yourself.  I 
> assume MIT does not want to follow that path.
> 
> 
> What I'd suggest is coming to an agreement about the minimal common schema 
> you need in order for the KDC to provide basic functionality, a way to 
> divide up the remaining namespace so you don't step on each others' toes, 
> and a perhaps a way to indicate the presence of a critical extension.  Note 
> that if you think you need the last for interop, you probably also need it 
> to support cross-version compatibility within your own implementation.
> 
> Once the initial agreement is in place, everything else can be done 
> unilaterally.

Has anything more happened on this?

I'm not as worried about the broader question of schema compatibility
(but it would be nice) as I am about this particular attribute (and
perhaps a representation of the password's last changed time).  That is,
these are attributes that an LDAP server might be expected to write to,
if it were to implement a single password for multiple protocols. 

That is, I would like something like the smbk5pwd OpenLDAP module (which
never really went anywhere, but demonstrates how this can work nicely)
to be possible, across multiple KDC implementations.  Avoiding another
case of separate MIT/Heimdal/xxx modules would be very welcome.

Another approach would be for Heimdal (and Samba4) to adopt the new
schema, but this presents the same issues of compatibility that caused
the concern about being 'locked in'.  

Schemas tend to stick, and I think the best we can do as suggested and
start with a sensible base that makes things as easy as possible, and
understand that even new MIT versions will cause schema extension.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20060816/5e2d1b32/attachment.bin