[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Fri, 2012-04-20 at 16:09 -0400, Dmitri Pal wrote:

> I was under the assumption that to be able to wrap things properly you
> need both user password in clear that you have only at the moment the
> hashes are created and the key for the branch office replica. Is this
> the wrong assumption? If you do not need raw password you can rewrap
> things later but you should do it only on the fly when the attribute is
> replicated. You do not want to create re-wrapped hashes  when the
> replica is added - that will be DDoS attack.
> If the assumption is correct then you would have to force password
> change every time you add a branch office replica.

The assumption is incorrect.
We can rewrap at replication tiem in a different master key, and that
doesn't require the user clear text password, only access to the old and
the new master key. A similar mechanism is used internally 

> > With a) the disadvantage are that it is an expensive operation, and also
> > makes it hard to deal with hubs (if we want to prevent hubs from getting
> > access to access krb keys).
> 
> Why this is a problem?

Performance wise it probably isn't a big deal after all, it will slow
down replication a bit, but except for mass enrollments it will not be
that big of an issue.
The main issue I see with hubs is that I was under the impression we
didn't want to let hubs be able to decrypt keys. In that case we can
handle only replicating to hubs that have a single 'branch office' they
replicate to because they will not be able to do an re-wrapping. That is
why I mentioned option (b) where you pre-generate copies for the target
branches. If we are ok giving hubs the ability to re-wrap keys, then it
is not an issue, as we can provide hubs with their own master key and
then we can re-wrap master -> hub and then again hub -> branch by giving
the hub also the branch master key.

> > With b) the disadvantage is that you have to create all other copies and
> > keep them around. So any principal may end up having as many copies are
> > there are branch offices in the degenerate case. It also make it
> > difficult to deal with master key changes (both main master key and
> > branch office master keys).
> >
> > Both approaches complicate a bit the initial replica setup, but not
> > terribly so.
> 
> So which one do you propose? It is not clear.

I am still unsure, both have advantages and drawbacks, see above about
hubs for example.

> >> > Using this approach we have several benefits:
> >> > 
> >> > 1) Remote office can enjoy the eSSO
> >> > 2) If the remote replica is jeopardized there is nothing in it that can
> >> > be used to attack central server without cracking the kerberos hashes.
> >> > 3) Authentication against the remote server would not be respected
> >> > against the resources in the central server creating confined environment
> >> > 4) Remote office can operate with eSSO even if there is no connection to
> >> > the central server.
> > Not so fast! :-)
> > User keys are not all is needed.
> > Re-encrypting user keys is only the first (and simplest) step.
> > Then you have to deal with a) the 'krbtgt' key problem and b) the Ticket
> > granting Service problem. They are solvable problems (also because MS
> > neatly demonstrated it can be solved in their RODC), but requires some
> > more work on the KDC side.
> >
> > So problem (a): the krbtgt.
> > When a user in a branch office obtain a ticket from the branch office
> > KDC it will get this ticket encrypted with the branch office krbtgt key
> > which is different from the other branch offices or the main ipa server
> > krbtgt key.
> > This means that if the user then tries to obtain a ticket from another
> > KDC, this other KDC needs to be able to recognize that a different
> > krbtgt key was used and find out the right key to decrypt the user
> > ticket to verify its TGT is valid before it can proceed.
> 
> I am not sure this needs to be solved. It depends what kinds of central
> services are required for the local office users to access. Can we defer
> this?

No. It is key to have this working, having a krbtgt that cannot be used
to acquire tickets is useless.

> > We also have a worse reverse problem, where a user obtained a krbtgt for
> > the ipa masters but then tries to get a service ticket from the branch
> > office TGS which does not have access to the main krbtgt at all (or it
> > could impersonate any user in the realm).
> > So for all these case we need a mechanism in the KDC to i) recognize the
> > situation ii) find out if it can decrypt the user tgt iii) either
> > redirect the user to a TGS server that can decrypt the tgt or 'proxy'
> > the request to a KDC that can do that.
> 
> Seems very complex and too generic. May be we should slice it into
> several use cases and address them one at a time.

It's a single use case, acquiring a ticket. Nothing we can really split
into discrete pieces.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York