Re: [Design] Re: multiple ipsec.secrets entries

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
	[email protected]
	rightrsasigkey=0s2b85da...
	left=%defaultroute
	[email protected]
	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: [email protected]
strongSec GmbH                    home:   http://www.strongsec.com
Alter Zürichweg 20                phone:  +41 1 730 80 64
CH-8952 Schlieren (Switzerland)   fax:    +41 1 730 80 65
==========================================[strong internet security]===


Content Security by MailMarshal