Re: MIT Incremental Propagation

2007-09-24 Thread Jeffrey Altman 
John Hascall wrote:
>>> Ubik is an elected-master protocol.  All updates go to the master
>>> which replicates.  If the master goes away, after a while the
>>> remaining nodes notice and revote a new master (this can take a while).
>>>
>>> I'm not sure that model works well with the KDC's single-threadedness.
>>>
>>> I expect a 3-phase commit model would be more robust.
>> I think you're conflating the master election protocol with the
>> transaction protocol.  You still need to decide on a master (aka
>> "coordinator") with 2PC or 3PC.
>
>You do not.  Each transaction can be mastered by whichever
>node it starts out on.  As soon as it has >50% acks to the
>prepare, it can issue the commits.  At the same time another
>node can be mastering a different transaction.
>
> John
Ken is describing a dynamically selected single master model whereas
John is describing a multiple master model.  They are simply different
models.  Ubik provides for an elected single master and does not support
multiple masters.

Jeffrey Altman



smime.p7s
Description: S/MIME Cryptographic Signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-24 Thread Ken Hornstein 
>   You do not.  Each transaction can be mastered by whichever
>   node it starts out on.  As soon as it has >50% acks to the
>   prepare, it can issue the commits.  At the same time another
>   node can be mastering a different transaction.

Fair enough; I stand corrected.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-22 Thread Marcus Watts 
> Date:Fri, 21 Sep 2007 16:52:59 EDT
> To:  John Hascall <[EMAIL PROTECTED]>
> cc:  [EMAIL PROTECTED], kerberos@mit.edu
> From:Ken Raeburn <[EMAIL PROTECTED]>
> Subject: Re: MIT Incremental Propagation 
> 
> On Sep 21, 2007, at 16:08, John Hascall wrote:
> > I haven't studied it all that extensively,
> > so correct me if I am wrong, but with the
> > new "DAL" stuff there is now an opportunity
> > to do a 'proper' job of multi-master KDCs
> > (dare I say it) in a "ubik-like" or "AD-like"
> > manner.
> 
> Yes, that's exactly right.  At least, in theory; I haven't tried it.   
> Using the LDAP back end -- ah, as I see Nico was just saying -- will  
> get you a common database shared across the KDCs, and leaves the  
> replication mechanism, if any, to the LDAP administrator.
> 
> Building something on Ubik might be a possibility.  I'm not that  
> familiar with it beyond "oh, that thing in AFS", but if it meets the  
> performance requirements for a KDC, yes, it could work.

ubik basically just provides a replicated flat file with transactions.
All the database stuff that AFS does is layered on top of this,
but ubik proper doesn't provide a database, just a byte stream
with seek and a length.

-Marcus Watts

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread John Hascall 

> >Ubik is an elected-master protocol.  All updates go to the master
> >which replicates.  If the master goes away, after a while the
> >remaining nodes notice and revote a new master (this can take a while).
> >
> >I'm not sure that model works well with the KDC's single-threadedness.
> >
> >I expect a 3-phase commit model would be more robust.
> 
> I think you're conflating the master election protocol with the
> transaction protocol.  You still need to decide on a master (aka
> "coordinator") with 2PC or 3PC.

   You do not.  Each transaction can be mastered by whichever
   node it starts out on.  As soon as it has >50% acks to the
   prepare, it can issue the commits.  At the same time another
   node can be mastering a different transaction.

John

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Ken Hornstein 
>Ubik is an elected-master protocol.  All updates go to the master
>which replicates.  If the master goes away, after a while the
>remaining nodes notice and revote a new master (this can take a while).
>
>I'm not sure that model works well with the KDC's single-threadedness.
>
>I expect a 3-phase commit model would be more robust.

I think you're conflating the master election protocol with the
transaction protocol.  You still need to decide on a master (aka
"coordinator") with 2PC or 3PC.  While Ubik does both the database
election and transaction protocol, this isn't really required.  And
from looking at the description of 3PC, I think Ubik as implemented
today would be considered 3PC, since transactions are aborted if a new
master needs to be elected.

Of course you wouldn't want to use Ubik as currently implemented today,
unless you really like having a dependency on AFS LWP & Rx.  I actually
wrote a completely new implementation of Ubik at one point ... the
recovery phase didn't quite work right, but I got busy with other things
before I could finish it.

As an aside ... I think the issue of the KDC being single/multithreaded
is a red herring.  I don't see a reason why the database update process
has to be part of the KDC process.  If you just restrict the multithreaded
parts to a seperate database update daemon, it shouldn't be a problem.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Donn Cave 
In article <[EMAIL PROTECTED]>,
 "Kevin Coffman" <[EMAIL PROTECTED]> wrote:

> On 9/21/07, Jeffrey Altman <[EMAIL PROTECTED]> wrote:
> > John Harris wrote:
> > > Greetings,
> > >
> > > Does MIT's current implementation of the Kerberos KDC include
> > > incremental propagation?  I know it didn't a long time ago, then there
> > > were CITI patches for it, then those didn't work for awhile.  I don't
> > > seem to be able to pinpoint an answer to it.
> > >
> > > Thanks,
> > >
> > > John
> > There is no incremental propagation distributed with MIT Kerberos.
> >
> > Jeffrey Altman
> 
> Our patch hasn't been ported forward to release 1.5 and beyond yet.
> With the new plugable database interface, changes are necessary.  We
> haven't had the time to get to it yet.

We haven't taken ours to a recent release level yet either, but
for other reasons.  It would be interesting, if academic, to see
if our approach would work with 1.6 without changes.  I think it
would - it's quite trivial, we just siphon off data (who, what)
from every change kadmind makes, and some other local software
takes it and applies to peer KDCs.  One or more of which are
Microsoft domain controllers (but only the MIT KDCs can propagate
changes.)  We've been doing this for ca 8 years.

As for an LDAP solution, we've talked about this here before
(cf. "LDAP KDB".)  If you need an LDAP backend for some other
reason, that's one thing, but just for replication, I don't
think so.

   Donn Cave, [EMAIL PROTECTED]

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Nicolas Williams 
On Fri, Sep 21, 2007 at 04:46:40PM -0500, John Hascall wrote:
> I'm not sure that model works well with the KDC's single-threadedness.

Which, really, should be multi-threaded...

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread John Hascall 

> Yes, that's exactly right.  At least, in theory; I haven't tried it.   
> Using the LDAP back end -- ah, as I see Nico was just saying -- will  
> get you a common database shared across the KDCs, and leaves the  
> replication mechanism, if any, to the LDAP administrator.
> 
> Building something on Ubik might be a possibility.  I'm not that  
> familiar with it beyond "oh, that thing in AFS", but if it meets the  
> performance requirements for a KDC, yes, it could work.

Well, ubik wouldn't exactly be my first choice, I just threw it
out as a possibly-known technology in the KDC replication protocol space.

Ubik is an elected-master protocol.  All updates go to the master
which replicates.  If the master goes away, after a while the
remaining nodes notice and revote a new master (this can take a while).

I'm not sure that model works well with the KDC's single-threadedness.

I expect a 3-phase commit model would be more robust.

John

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Kevin Coffman 
On 9/21/07, John Hascall <[EMAIL PROTECTED]> wrote:
>
> > John Harris wrote:
> > > Does MIT's current implementation of the Kerberos KDC include
> > > incremental propagation?  I know it didn't a long time ago, then there
> > > were CITI patches for it, then those didn't work for awhile.  I don't
> > > seem to be able to pinpoint an answer to it.
>
> Jeffrey Altman replied:
> > There is no incremental propagation distributed with MIT Kerberos.
>
> I haven't studied it all that extensively,
> so correct me if I am wrong, but with the
> new "DAL" stuff there is now an opportunity
> to do a 'proper' job of multi-master KDCs
> (dare I say it) in a "ubik-like" or "AD-like"
> manner.
>
> Is there anybody out there already looking at this?

My intention is to make our patch a "plugin wrapper", and hopefully
something that would eventually acceptable to be included in the
distribution.  I think that one of the big turn-offs initially was its
use of threads.  With the thread-safe library, I hope that is less of
a deterrent.

K.C.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Ken Raeburn 
On Sep 21, 2007, at 16:08, John Hascall wrote:
> I haven't studied it all that extensively,
> so correct me if I am wrong, but with the
> new "DAL" stuff there is now an opportunity
> to do a 'proper' job of multi-master KDCs
> (dare I say it) in a "ubik-like" or "AD-like"
> manner.

Yes, that's exactly right.  At least, in theory; I haven't tried it.   
Using the LDAP back end -- ah, as I see Nico was just saying -- will  
get you a common database shared across the KDCs, and leaves the  
replication mechanism, if any, to the LDAP administrator.

Building something on Ubik might be a possibility.  I'm not that  
familiar with it beyond "oh, that thing in AFS", but if it meets the  
performance requirements for a KDC, yes, it could work.



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Nicolas Williams 
On Fri, Sep 21, 2007 at 03:29:16PM -0500, John Hascall wrote:
> > There are plenty of LDAP servers suitable for backending the KDC that
> > support incremental and/or multi-master replication.
> 
> That, I suppose, depends on your definition of "suitable".
> It certainly isn't suitable to me.  The size of the KDC
> codebase is big enough to worry about, throwing something
> like an entire LDAP server into the mix is a whole 'nother
> kettle of fish.

Maybe.  If you run the LDAP servers for the KDC backend such that only
the KDCs can be clients of it, with proper packet filtering, then there
won't be much room for new attack vectors.

Whereas if you use an LDAP server infrastructure that's also used for
other things, like name services, then you'd be exposing the KDCs to
attack via hostile (p0wned) directory services.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Russ Allbery 
Nicolas Williams <[EMAIL PROTECTED]> writes:
> On Fri, Sep 21, 2007 at 03:54:22PM -0400, Jeffrey Altman wrote:
>> John Harris wrote:

>>> Does MIT's current implementation of the Kerberos KDC include 
>>> incremental propagation?  I know it didn't a long time ago, then there 
>>> were CITI patches for it, then those didn't work for awhile.  I don't 
>>> seem to be able to pinpoint an answer to it.

>> There is no incremental propagation distributed with MIT Kerberos.

> Not to spam but, the OpenSolaris KDC does have incremental propagation.
> The source for that is CDDL'ed.

Well, if we're going to talk about other KDC implementations, Heimdal does
incremental replication as well for that matter.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Kevin Coffman 
On 9/21/07, Jeffrey Altman <[EMAIL PROTECTED]> wrote:
> John Harris wrote:
> > Greetings,
> >
> > Does MIT's current implementation of the Kerberos KDC include
> > incremental propagation?  I know it didn't a long time ago, then there
> > were CITI patches for it, then those didn't work for awhile.  I don't
> > seem to be able to pinpoint an answer to it.
> >
> > Thanks,
> >
> > John
> There is no incremental propagation distributed with MIT Kerberos.
>
> Jeffrey Altman

Our patch hasn't been ported forward to release 1.5 and beyond yet.
With the new plugable database interface, changes are necessary.  We
haven't had the time to get to it yet.

K.C.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Nicolas Williams 
On Fri, Sep 21, 2007 at 03:54:22PM -0400, Jeffrey Altman wrote:
> John Harris wrote:
> > Greetings,
> >
> > Does MIT's current implementation of the Kerberos KDC include 
> > incremental propagation?  I know it didn't a long time ago, then there 
> > were CITI patches for it, then those didn't work for awhile.  I don't 
> > seem to be able to pinpoint an answer to it.
> >
> > Thanks,
> >
> > John
> There is no incremental propagation distributed with MIT Kerberos.

Not to spam but, the OpenSolaris KDC does have incremental propagation.
The source for that is CDDL'ed.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread John Hascall 

> > I haven't studied it all that extensively,
> > so correct me if I am wrong, but with the
> > new "DAL" stuff there is now an opportunity
> > to do a 'proper' job of multi-master KDCs
> > (dare I say it) in a "ubik-like" or "AD-like"
> > manner.

> There are plenty of LDAP servers suitable for backending the KDC that
> support incremental and/or multi-master replication.

That, I suppose, depends on your definition of "suitable".
It certainly isn't suitable to me.  The size of the KDC
codebase is big enough to worry about, throwing something
like an entire LDAP server into the mix is a whole 'nother
kettle of fish.

John

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Nicolas Williams 
On Fri, Sep 21, 2007 at 03:08:26PM -0500, John Hascall wrote:
> > > Does MIT's current implementation of the Kerberos KDC include 
> > > incremental propagation?  I know it didn't a long time ago, then there 
> > > were CITI patches for it, then those didn't work for awhile.  I don't 
> > > seem to be able to pinpoint an answer to it.
> 
> > There is no incremental propagation distributed with MIT Kerberos.
> 
> I haven't studied it all that extensively,
> so correct me if I am wrong, but with the
> new "DAL" stuff there is now an opportunity
> to do a 'proper' job of multi-master KDCs
> (dare I say it) in a "ubik-like" or "AD-like"
> manner.

There are plenty of LDAP servers suitable for backending the KDC that
support incremental and/or multi-master replication.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread John Hascall 

> John Harris wrote:
> > Does MIT's current implementation of the Kerberos KDC include 
> > incremental propagation?  I know it didn't a long time ago, then there 
> > were CITI patches for it, then those didn't work for awhile.  I don't 
> > seem to be able to pinpoint an answer to it.

Jeffrey Altman replied:
> There is no incremental propagation distributed with MIT Kerberos.

I haven't studied it all that extensively,
so correct me if I am wrong, but with the
new "DAL" stuff there is now an opportunity
to do a 'proper' job of multi-master KDCs
(dare I say it) in a "ubik-like" or "AD-like"
manner.

Is there anybody out there already looking at this?

John

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Incremental Propagation

2007-09-21 Thread Jeffrey Altman 
John Harris wrote:
> Greetings,
>
> Does MIT's current implementation of the Kerberos KDC include 
> incremental propagation?  I know it didn't a long time ago, then there 
> were CITI patches for it, then those didn't work for awhile.  I don't 
> seem to be able to pinpoint an answer to it.
>
> Thanks,
>
> John
There is no incremental propagation distributed with MIT Kerberos.

Jeffrey Altman



smime.p7s
Description: S/MIME Cryptographic Signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

MIT Incremental Propagation

2007-09-21 Thread John Harris 
Greetings,

Does MIT's current implementation of the Kerberos KDC include 
incremental propagation?  I know it didn't a long time ago, then there 
were CITI patches for it, then those didn't work for awhile.  I don't 
seem to be able to pinpoint an answer to it.

Thanks,

John

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos