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

Paul Wouters wrote:
> On Fri, 28 Feb 2003, Andreas Steffen wrote:
> 
> 
>>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.
> 
> 
> I don't think this is always true. The case that Ken and me
> ran into a few days ago that prompted our question was the
> Opportunistic Encryption case. It seems that if a roadwarrior
> initiates a connection to a gatway that uses both a certificate
> and opportunistic encryption, things get confused. I believe
> this is happening:
> 
> 1) Incoming udp 500 from certificates based road warrior
> 2) gateway detects incoming and adds a %shunt(?) eroute, blocking
>    communication while trying to do opportunistic encryption.

This cannot be true. If roadwarrior connection definitions exists
FreeS/WAN as a responder will first try these before falling back to 
opportunistic mode. Can you provide a barf?

> 3) opportunistc encryption failed, road warrior doesnt support it
>    and a %pass follows
> 4) roadwarrior sends its ID, and Pluto disgards it as part of a
>    "previous exchange".

Actually this has nothing to do with the selection of private keys
but rather with the simultaneous interaction of opportunistic mode
and "normal" roadwarrior connections.

> I might be wrong in the inner workings of Pluto, but the OE connection
> is definately causing it to interfere with the X509 connection. We
> see interleeaving log entries, suggesting these connectin attempts
> happen at the same time.

Again, please provide a barf.

> 
>>- 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.
> 
> 
> We started experimenting with this, but didn't finish it so far. What
> needs to be tested is trying to have a 'normal' raw key connectin and
> an x509 based one work properly using the proper definitions in the
> ipsec.secrets file, and only then try to add the complexity of
> Opportunistic Encryption.
> 
> 
>>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.
> 
> 
> I'll leave those decisions up to the people involved. I'm just a volunteer :)
> (But instinct tells me "go for it" :)
> 
> I do wonder whether it is possible to distinguish the opportunistic
> encryption's secret from other secrets more clearly, so that pluto 
> doesn't need to fight with itself if it is supporting OE and X509.
> 
> Paul

Regards

Andreas

=======================================================================
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