On Mon, 2012-04-23 at 13:04 -0400, Dmitri Pal wrote:
> 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.

Not really.

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

I would want to do this, it would require intimate knowledge of stuff a
client isn't supposed to know, and would be a big change in the library
for a temporary change.

But most importantly, this would address only clients you control, and
we do not control all of the clients. I do not like having a core
feature work only for a subset of machines, and leave the others
completely broken.

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

Not really, it would require for the client to know how to distinguish
tickets (hint: it can't :-)

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

To a client the krbtgt issue from on or another KDC of the same realm is
indistinguishable. The krbtgt is encrypted and the client has not way to
know what's in it.

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

The problem here is that you cannot ""re-authenticate"" if you are not a
user in the local replica. Even putting aside the ugliness of having to
explain your users what to do which will be very difficult.
A roaming user visiting a branch office (say a manager going to visit an
office abroad) never has it's credentials in the branch office, so he
will always need to have it's request to the local KDC proxied to one of
the master KDCs, even if we could redirect instead of proxy then any
access to local resources would still need to go thorough the main KDc
because the local branch office does not know how to crack open the user
If, we implement proxying instead the central KDC can give back to the
branch KDC that is proxying the request a krbtgt that is encrypted with
the branch office KDC krbtgt key, so that all following interactions can
be done at the branch office level for branch office controlled

Let's put it this way, I would rather defer this feature completely by a
year than try to do it in steps as you describe.


Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to