On Wed, May 12, 2010 at 4:38 PM, Dmitri Pal <d...@redhat.com> wrote: > Rob Townley wrote: >> The main difference between tinc vpns and traditional vpns is that >> tinc is bidirectional and does not require the user to enter a >> username password. So if the computer is turned on, the remote >> machine is reachable by the IT department. If it is a windows >> machine, you may want to verify antivirus signatures are up-to-date. >> FusionInventory could be used to push software. >> >> Yes, it is a machine level as opposed to user level vpn. tinc would >> have to run all machines to make it the easiest to use. With freeipa, >> that could be easy. >> >> The keys currently are RSA public / private keypairs. >> >> Does not have existing code to work with ldap / kerberos as far as i know. >> > > Would be great if it could leverage kerberos for this. > Then it would have been really easy with IPA and no need for additional > key management. > Host keytabs are already managed by FreeIPA v2. > But certmonger would be able to help with certs too. > Have you looked at cernmonger as a provisioning tool for that sort of > deployment? > Again freeIPA v2 is capable of handling certs for this case too.
Would love to see more kerberized services instead of ldapified services. But not clear how kerberos would fit in with tinc. When i think of kerberos, i think of ticket requests to a fleet of ticket granting servers which reply with a dual stamped ticket that both me and a less trusted third party can use for mutual auth. What i like about kerberized services is that i don't have to send my password to a less trusted third party like you do with LDAP (AFAIK - definitely not without user certificates). Because of this weakness of LDAP, i can't outsource our timetrex timeclock ldapified webserver and give employees single sign on because that would mean an untrusted third party would have all our passwords. A kerberized timetrex service could be enrolled with least privilege but still give employees sso and without sending a password to anything but a kdc. i love kerberos, but it isn't PKI by itself, it is tickets, so it isn't totally clear how the two work together, but i am sure freeipa provides that glue. I looked at certmonger and certmaster and from there looked at func. Looks like key management and local key storage can be done by the func platform and the vpn service could be one of the consumers of the func certificate platform. Central key management would be done by certmaster or freeipa. Looks promising, but none of the client side appears cross platform for the MacWin workstations. i thought nss or sss would be the crossplatform local key store. i have no idea if it is realistic to modify tinc to use gssapi / spnego, but i believe it then could get kerberos tickets and access to the same local certs and be crossplatform? One potential advantage of kerberos / ldap would be having different groups with different access levels to the other nodes. You say it would be easier for the key management if it was kerberized, what other advantages? > > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users