[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 04/20/2012 04:29 PM, Simo Sorce wrote:
> 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.
>
I disagree. I see at least several use cases:

1) User has TGT form the branch office replica and needs to access a
resource in the branch office
2) User has TGT form the branch office replica and needs to access a
resource in the central data center
3) User has TGT form the central replica and needs to access a resource
in the branch office

Not all of the scenarios need to be addressed day 1.
May be we just focus on  1and then extend to 2 and defer 3 till later?



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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