[Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[Nathaniel McCallum]

On Sat, 2014-09-20 at 17:33 -0400, Simo Sorce wrote:
> On Sat, 20 Sep 2014 15:39:48 -0400
> Nathaniel McCallum <npmccallum at redhat.com> wrote:
> 
> > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote:
> > > Hello Nathaniel,
> > > 
> > >         sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD.
> > > It looks good but difficult to think to all possible cases.
> > >         I think to the following corner case:
> > >         The initial entry has ipatokenHOTPcounter=5
> > >         ldapmodify..
> > >         changetype: modify
> > >         add: ipatokenHOTPcounter
> > >         ipatokenHOTPcounter: 6
> > >         -
> > >         replace: ipatokenHOTPcounter
> > >         ipatokenHOTPcounter: 7
> > >         
> > >         It translates
> > >         add: 6
> > >         del: 5
> > >         add: 7
> > >         
> > >         This operation will fail because ipatokenHOTPcounter is
> > >         single-valued although IMHO it should succeed.
> > 
> > No. It should fail. There can only ever be one ipatokenHOTPcounter.
> > 
> > >         This is a so special operation that is may not really be a
> > >         concern.
> > 
> > +1
> > 
> > >         It is important that attribute are single valued. The
> > >         replication changelog will replicated MOD/DEL + MOD/ADD for
> > > a MOD/REPL.
> > >         That means that if the attributes are updated on several
> > >         masters, the number of values can likely increase. Where for
> > >         single value it should only keep the most recent value.
> > 
> > That is a concern, at least for now. Eventually we won't use
> > replication for this at all. But for now, we will.
> > 
> > Here is the problem I foresee. You have two servers: A and B.
> > 
> > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1).
> > Replication is sent to server B.
> > 
> > Before the replication is performed on server B, the user
> > authenticates with the next token. This triggers a
> > MOD/DEL(0)+MOD/ADD(2). Replication is sent to server A. This
> > replication will fail because A has a value of 1, not a value of 0.
> > 
> > The end result is that there will be different values for
> > ipatokenHOTPcounter on the two different servers. A will have 1 and B
> > will have 2. Once this happens, the replications can never reconcile
> > (this is a big problem). I see two options here, both theoretical.
> > 
> > Option #1 is to hook 389 in a different place: before the mods are
> > performed by after the replication changelog is generated.
> > Alternatively, we could insert a hook after the replication changelog
> > is generated, but before it is sent. We could consolidate the MOD/DEL
> > +MOD/ADD here into a single MOD/REPLACE operation.
> > 
> > Option #2 is to have some way to translate the MOD/REPLACE(X) into a
> > MOD/DEL(<=X)+MOD/ADD(X).
> > 
> > Are either of these possible? Is there another option?
> 
> I think the only option would be to intercept modifications on
> replicas, check that the mod is due to a replication event and
> discard/change the delete and change the add into a replace. This means
> replay attacks will still be possible, but there is no way around that
> until we handle the replication/quorum thing ourselves.

Attached is a new version. This version replays the counter value
through the mod steps. This allows us to discard delete values when
doing replication and fill them in with the current counter value. It
also allows us to play all the steps and check our parameters on the
final state. I've tested with some fairly complex ldifs and I haven't
seen any bugs. I think this should fix all the outstanding problems.

Nathaniel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-npmccallum-0064.3-Create-ipa-otp-decrement-389DS-plugin.patch
Type: text/x-patch
Size: 17758 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140921/f6b8fede/attachment.bin>