|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [Design] Re: [Users] multiple ipsec.secrets entries
Date: Fri Feb 28 2003 - 05:57:42 EST
Let's assume the following scenario
ipsec.conf:
conn rw_A
right=%any rightid="C=CH, O=foo CN=client A" rsasigkey=%cert left=%defaultroute leftcert=freeswan_fooCert.pem conn rw_B right=%any rightid="C=CH, O=bar, CN=Client B" rsasigkey=%cert left=%defaultroute leftcert=freeswan_barCert.pem conn rw_C right=%any rightid=@clientc.rawrsa.org rightrsasigkey=0s2b85da... left=%defaultroute leftid=@freeswan.rawrsa.org leftrsasigkey=0s348a5d..
ipsec.secrets:
: RSA {
<standard FreeS/WAN RSA private key>
}
: RSA freeswan_barKey.pem
: RSA freeswan_fooKey.pem
roadwarrior connections A and B are based on X.509 certificates issued by two different CAs (foo and bar) and using different private keys whereas connection C is based on raw RSA keys (could also be opportunistic) having a third private key.
Certificate based connections always find the correct private key in ipsec.secret because a link to the certificate loaded via the leftcert command is maintained in the connection description which allows to match the public key contained in the certificate to the public key in the private key representation.
With raw RSA keys it is different because no public key information is available in the connection description (although there is a leftrsasigkey parameter this information is currently disregarded because the local side needs only its private key in order to sign the hash in IKE Main mode).
Standard FreeS/WAN explicitly does not allow multiple anomymous RSA private keys in ipsec.secrets because it cannot differentiate them. This is why the warning
>Pluto[24727]: "roadwarrior-net" 206.26.195.236 #6:
multiple ipsec.secrets entries with distinct secrets match endpoints: first secret used
is generated.
Current workaround:
- Put the raw private key first on the list in ipsec.secrets. Since in the presence of multiple secrets always the first is taken, this will work out correctly for connections based on raw RSA keys.
An unlimited number of anonymous RSA private keys can follow. If they belong to an X.509 certificate loaded via the [left|right]cert parameter, the correct key will always be found. Attention: This is not valid if FreeS/WAN's cert is loaded via the /etc/x509cert.der file. This is the actual reason that its use is deprecated and why it has been eliminated in the X.509 patch for freeswan-2.00.
Proper workaround:
- Although not mandatory, the local public key can be defined in connections based on raw RSA keys by using the leftrsasigkey parameter. Since X.509-1.1.6 for freeswan-2.00 alread supports both X.509 and OpenPGP certificates, as a thirk class, a link to the raw public key could be created in the connection description which would allow the private key to be found in ipsec.secrets irrespective of its position in the list. This would also introduce support of multiple RSA private keys in roadwarrior connections based on raw RSA public keys. I could implement this feature within the next month but for freeswan-2.00, only.
Regards
Andreas
Paul Wouters wrote:
> On Tue, 25 Feb 2003, Road Warrior wrote: > > (I have CC:ed this to design@ since I believe this is a design problem) > > >>I then noticed this on the gateway logs: Feb 25 19:25:32 sparta >>Pluto[24727]: "roadwarrior-net" 206.26.195.236 #6: multiple ipsec.secrets >>entries with distinct secrets match endpoints: first secret used > > > >>The other three connections [understandably] could not be made. >> >>How do I work around this? >>Can I have multiple ipsec.secrets entries? >> >>I am using Linux FreeS/WAN 1.96 from debian stable. > > > Though 1.96 is an old version, I've recently encountered the same problem. > You can find some information in the man page for ipsec.secrets, and there > it says you can use multiple secrets, and that the "most exact" match for > a secret is used. > > However, I believe that scheme is no longer properly functioning, though > I have yet to pinpoint what causes the failure. I think mixing x509 > certificates and RSA keys is what is no longer working properly. The latter > is used for Opportunistic Encryption, and in the 2.x series, this > connection will be enabled by default (even if the connection is not > specified in the ipsec.conf). Therefor, I believe anyone who is going to > run X.509 certificates with Freeswan 2.x will run into this problem. > > If you just want multiple road warriors to connect to your gateway, > each using their own certificate, by far the easiest approach is to > use a "certificate agency" that signs all the certificates > of your roadwarriors. Then you only need to load the certificate of the > CA on the gateway. You can use this together with a revocation list to > disallow certain signed certifictes which administratively no longer > should be valid, but are still valid technically (as specified in the > signature of the ca). A good link on how to accomplish this is: > > http://www.natecarlson.com/linux/ipsec-x509.php > > Perhaps DHR and Stefan can comment on how it might be possible to get > X509 and RSA secrets to co-exist in Pluto? And if so, then perhaps > Claudia can put this information in the FAQ? > > Paul ======================================================================= Andreas Steffen e-mail: andreas.steffen@strongsec.com strongSec GmbH home: http://www.strongsec.com Alter Zürichweg 20 phone: +41 1 730 80 64CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===
Content Security by MailMarshal
Design mailing list
Design@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/design Received on Fri Feb 28 17:37:12 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:32 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |