Re: [strongSwan] a particular ``no trusted third party'' setup with X.509
Dimitrios Siganos dimitris... writes: [...] * when there're no trusted third party to serve as the CA to sign the certificates for the hosts belonging to the sites, each of the sites should sign the certificates used by the hosts of the other site to connect to the hosts of this site (i. e., each of the sites effectively becomes a CA)? [...] Oops. I fell into the trap of thinking small scale. If you are talking about large scale installations then your way is probably recommended. Actually, I don't know whether the installation's going to be small or large at this moment. But if there's no known issues with the arrangement above, I'll prefer doing it that way, as it scales better. Thanks. [...] -- FSF associate member #7257 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] a particular ``no trusted third party'' setup with X.509
The question is not quite strongSwan-specific, but I'm going to ask it anyway. Consider, e. g., two sites which are going to establish secure communication. Each of the sites is comprised of a set of IKEv2-enabled hosts. Do I understand it correctly that with strongSwan: * it's not necessary to use X.509, though it may make maintenance easier; * when there're no trusted third party to serve as the CA to sign the certificates for the hosts belonging to the sites, each of the sites should sign the certificates used by the hosts of the other site to connect to the hosts of this site (i. e., each of the sites effectively becomes a CA)? With each of the sites being its own CA, tasks such as removing an other site's host from the set of the ``trusted ones'' (for whatever reason) could be accomplished by just revoking the respective certificate. IIUC, this scheme is applicable to the other protocols that allow mutual authentication based on X.509 certificates (say, SMTP.) Or are there any known deficiencies? -- FSF associate member #7257 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] a particular ``no trusted third party'' setup with X.509
Ivan Shmakov wrote: Consider, e. g., two sites which are going to establish secure communication. Each of the sites is comprised of a set of IKEv2-enabled hosts. Do I understand it correctly that with strongSwan: * it's not necessary to use X.509, though it may make maintenance easier; You are right. It is not necessary to use x509. For example you can also use: a) shared password, b) rsa keys. * when there're no trusted third party to serve as the CA to sign the certificates for the hosts belonging to the sites, each of the sites should sign the certificates used by the hosts of the other site to connect to the hosts of this site (i. e., each of the sites effectively becomes a CA)? Yes, you could do that, but you don't have to go to that length and probably shouldn't. Certificates without a trusted third party don't give you anything more (from a security point of view) than straight rsa keys. You don't need CAs. You can just use rsa keys or self signed certificates or even unique shared secrets for each link. With each of the sites being its own CA, tasks such as removing an other site's host from the set of the ``trusted ones'' (for whatever reason) could be accomplished by just revoking the respective certificate. If you use self-signed certficates or rsa keys, revoking is the act of deleting the key/cert from trusted store. IIUC, this scheme is applicable to the other protocols that allow mutual authentication based on X.509 certificates (say, SMTP.) Or are there any known deficiencies? Self-signed certificates would apply to other protocols that use certificate based authentication. Straight rsa keys and shared passwords, wouldn't. Regards, Dimitrios Siganos ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] a particular ``no trusted third party'' setup with X.509
Oops. I fell into the trap of thinking small scale. If you are talking about large scale installations then your way is probably recommended. Dimitrios Siganos Dimitrios Siganos wrote: Ivan Shmakov wrote: Consider, e. g., two sites which are going to establish secure communication. Each of the sites is comprised of a set of IKEv2-enabled hosts. Do I understand it correctly that with strongSwan: * it's not necessary to use X.509, though it may make maintenance easier; You are right. It is not necessary to use x509. For example you can also use: a) shared password, b) rsa keys. * when there're no trusted third party to serve as the CA to sign the certificates for the hosts belonging to the sites, each of the sites should sign the certificates used by the hosts of the other site to connect to the hosts of this site (i. e., each of the sites effectively becomes a CA)? Yes, you could do that, but you don't have to go to that length and probably shouldn't. Certificates without a trusted third party don't give you anything more (from a security point of view) than straight rsa keys. You don't need CAs. You can just use rsa keys or self signed certificates or even unique shared secrets for each link. With each of the sites being its own CA, tasks such as removing an other site's host from the set of the ``trusted ones'' (for whatever reason) could be accomplished by just revoking the respective certificate. If you use self-signed certficates or rsa keys, revoking is the act of deleting the key/cert from trusted store. IIUC, this scheme is applicable to the other protocols that allow mutual authentication based on X.509 certificates (say, SMTP.) Or are there any known deficiencies? Self-signed certificates would apply to other protocols that use certificate based authentication. Straight rsa keys and shared passwords, wouldn't. Regards, Dimitrios Siganos ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
