[Openswan dev] Openswan patches (fwd)

[Avesh Agarwal]

On 07/10/2010 02:00 PM, Paul Wouters wrote:
> 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.
>    
That is right. I am suggesting that whack can read the secrets from 
stdin written in the same format as of ipsec.secrets, parse them, and 
pass them to pluto in the whack messsage.
> What is the idea behind secrets from stdin?
>    
NetworkManager assumes that information (connection configurations and 
secrets) entered by users should not be written to the file system.

Avesh
> 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.
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
>