[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 04/19/2012 07:43 PM, Simo Sorce wrote:
> Ok, this come close to a proper solution but not quite.
> So first of all, kerberos keys are available in the master, we do not
> need to also store the clear txt password and regenerate them, but we do
> need to be able to convey them to the replica wrapped in a different
> master key.
>
> Let me explain what I had in mind to attack this problem (I hinted at it
> in a previous email).
>
> The simplest way is to use a principal named after the branch office
> replica as the 'local'-master and (possibly a different one)
> 'local'-krbtgt key, this way the key is available both to the FreeIPA
> masters and to the branch replica.
>
> Assume a realm named IPA.COM we would have principals named something
> like krbtgt-branch1.ipa.com at IPA.COM
>
> As for transmitting these keys we have 2 options.
> a) similar to what you describe above, unwrap kerberos keys before
> replication and re-wrap them in the branch office master key.

> b) store multiple copies of the keys already wrapped with the various
> branch office master keys so that the replication plugin doesn't need to
> do expensive crypto but only select the right pair

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.
> 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?

> 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.

>> > 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?

> 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.

> The problem in (b) is of the same nature, but stems from the problem
> that the branch office KDC will not have the keys for a lot (or all) of
> the service principal for the various servers in the organization.
> So after having solved problem (a) now we need again to either redirect
> the user to a TGS that have access to those keys so it can provide a
> ticket, or we need 'proxy' the ticket request to a server that can.
>
>
> In general we should try to avoid tring to 'redirect' because referrals
> are not really well supported (and not really well standardized yet) by
> many clients and I am not sure they could actually convey the
> information we need to anyways, so trying to redirect would end up being
> an inferior solution as it would work only for a tiny subset of clients
> that have 'enhanced' libraries.
> OTOH proxying has a couple of technical problems we need to solve.
> The first is that we need a protocol to handle that, but using something
> derived from the s4u2 extensions may work out. The second problem is
> that it requires network operations in the KDC, and our KDC is not
> currently multithreaded. However thanks to the recent changes to make
> the KDC more async friendly this may not be a problem after all. As the
> KDC could shelve the request until a timeout occurs or the remote KDC
> replies with the answer we need.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/