CCing freeipa-devel so that others can benefit from replies too. On Wed, 2011-11-09 at 09:49 -0500, Dan Scott wrote: > > Well in 2-way trusts you could do that. But in general you do not want > > to have any client in realm1 to contact any server in realm2. They might > > be geographically very far and use high latency/low bandwidth links. > > I must be missing something here. Why does it need to be a 2-way > trust?
Because otherwise you may not have access to the keys at all unless anonymous binds are allowed (this is the default indeed). > My local IPA server doesn't have to trust the remote IPA server > at all, does it (other than encryption/certificates to prevent a MITM > - although the existing system doesn't help with that either, for the > initial host key transfer)? Even then, wouldn't an unauthenticated > LDAP lookup be OK for transferring the host keys? No, this is the other aspect. With GSSAPI auth you have mutual authentication. This means you can trust the remote server. If you just let clients do anonymous binds and fetch data from a server w/o authentication then it is easy for an attacker to MITM the LDAP connection and give you public keys for a ssh server that will also MITM you. I know that in many environments people will consider this an unlikely threat and not care about it, so maybe an RFC to allow SSSD to do this with un-authenticated connections will be allowed. > My client would be trying to contact a system in the other realm > anyway, so I don't really see the latency/bandwidth problems. It depends on the architecture of your specific setup. I was giving generic reasons why. > Surely > whatever I'm doing over SSH will require more bandwidth than the key > transfer. Maybe, maybe not, you may have a host in your local lan that belongs to a remote realm and only the KDC/LDAP server is remote to you. > Instead of my client contacting the remote SSH host > directly. My local SSSD would contact the other realm's IPA server to > get the key of the host I'm connecting to. Even then, this would be a > 'one-time' key transfer although it would need to be re-checked > occasionally. Yes, hence we may allow it. > > So, for a first implementation, we could do what you say, but I rather > > think it through and see how to cache/transfer information making > > clients go through their IPA server rather than trying to connect > > directly to a remote one. > > Sure, makes sense. Getting it working in one realm is the priority. There is also another reason why going through a 'proxy' service is useful. If you have different IPA versions (or even different DC technology like IPA vs AD) on the 2 sides of the trust we would be able to build a 'translation' service on the IPA server so that clients do not need to learn how to speak to other Identity Domains directly. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
