On 04/23/2012 10:02 AM, Simo Sorce wrote: > On Mon, 2012-04-23 at 09:54 -0400, Dmitri Pal wrote: >> 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 > This will work > >> 2) User has TGT form the branch office replica and needs to access a >> resource in the central data center > This will fail This will fail if we do not what you propose, right? And I think we can do it in iterations. May be it can be fixed in the kerberos library on the service side to allow it acquiring its own ticket against different KDCs with different krbtgts in parallel. Then when the user from a branch office accesses the service the service would have multiple tickets and would be able to see which one to use? I am a bit vague here as I do not know exactly what the issue is and how exactly the service deals with the user ticket that is issued by KDCs with different krbtgt so please correct me.
>> 3) User has TGT form the central replica and needs to access a resource >> in the branch office > This will fail And this should not be a big deal. If you have access to the branch office service you probably can re-authenticate against branch office replica. IMO this is a corner case. >> 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? > The problem is that you have no fallback case. > If the central office have kerberized resources you may simply get > access denied and that's it. > Having the wrong ticket is not always the same as not having a ticket. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
