[Openswan dev] Openswan patches (fwd)

[Paul Wouters]

You're looking for input from others as well.....

Paul

| From: Paul Wouters <paul at xelerance.com>
| To: Avesh Agarwal <avagarwa at redhat.com>
| Cc: D. Hugh Redelmeier <hugh at mimosa.com>
| Subject: Re: Openswan patches
|
| On Fri, 9 Jul 2010, Avesh Agarwal wrote:
|
| > Are you planning to read secrets from standard input (stdin) too?
|
| I was thinking of only via whack, but if it can be done securely via
| stdin, that could be an option too.

Who would read secrets for stdin?  Certainly not Pluto -- that's not a
reasonable change.  For one thing, Pluto should not block.  Whack
could read stdin if that were desirable.

What is the idea behind secrets from stdin?

The original design (which may not be comprehensive enough) was that
secrets would be static and shouldn't hide anywhere that might get
lost over a restart.

If you think secrets are more dynamic, perhaps you could explain their
lifetime -- who creates them and manages them and communicates them
and why.

| > Also are secrets going to be per connection? I checked the code, and found
| > that although conf file can be read from stdin but not secrets (please let
| > me know if I am missing something). I always wonder why there is no choice
| > of per connection secrets in pluto. That is not to say that I do not see any
| > advantages in the current approach.
|
| Hugh might be able to tell. It would be nice to be able to do secrets per
| connection, so we could add/remove the secrets with the connection. But
| secrets can span multiple conns. I was thinking if we could/should allow
| for per-conn secrets on top of the "secrets pool". Hugh, what do you think?

In a lot of cases, connections are tentative.  Whenever Pluto is
responding, it is only guessing at a connection and may well switch
between them as more about the negotiation is revealed.  Even when a
connection is initiated, subsequent rekeying might be initiated by the
other side so the connection might be tentative too.  If a connection
is initiated due to catching a packet, again the inferred connection
is tentative.  So tying secrets to connections may not be correct.

Already the tentative nature of connection selection is fragile.
Putting even more detail in connections that might be tentative could
make this worse.

In theory, secrets are about identity.  That is why ipsec secrets is a
mapping from identity or pairs of identities to secret.  Of course one
could add more conditions: map from identities and contexts (of some
sort) to secret.

If you want to change this, you ought to have a good theory about why
it is wrong.


| From: Paul Wouters <paul at xelerance.com>

| On Fri, 9 Jul 2010, Avesh Agarwal wrote:
|
| > On a similar note, as openswan has leftcert and leftrsasigkey, how about if
| > openswan has leftxauthpassword and leftpsk (something like this) too?
|
| That would move "secrets" into the ipsec.conf or include files, which is what
| the design preventd from happening.  ipsec.conf can be read by anyone because
| it contains no secrets.

True and important.