Rob Townley wrote: > 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? > > If/when the tinc is kerberized then the following sequence of operations would happen:
The client side of the VPN connection tries to connect to the server side of the VPN connection. Both sides are assumed to be manged hosts in the same enterprise. They both are managed by IPA and have a keytab provision to them and belong to the same kerberos realm (same IPA domain). The server side of the VPN connection will reguire client to present a ticket destined for that service. The client side would have to request that ticket from KDC. So the client will first acquire so called TGT (ticket granting ticket) using keytab (machine password). As soon as client has TGT it can be used for several hours (usually 8 - 24) to acquire tickets to access other services (server side of the tinc connection). All this happens automatically behind the scenes and implemented by the kerberos libraries. Tinc just needs to implement GSS API (which is a complex API but still...) This is the main advantage - no need to deal with the PKI infrastructure, cert provisioning etc. But of cause it is written with Linux laptops in mind. With Windows this will be more complex and IPA is not there yet to handle native windows clients. There are ways to configure windows machines to be a part of the Kerberos realm and thus IPA but I am not sure if you would want to go this route. >> >> -- >> 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 > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
