2.02; Users-Moderated; OE-X.509

-----BEGIN PGP SIGNED MESSAGE-----



lists.freeswan.org Email Summary for Tuesday September 9, 2003
===============================================================================
by Claudia Schmeing                                        [email protected]


In this issue.... There's an experimental, moderated version of the 
FreeS/WAN users' list. See Item 1. FreeS/WAN now has a new release,
2.02, with a few small improvements that we've added over the summer.
An interesting new potential development, X.509-OE, is covered in Item 4.

Enjoy.



This Week in Brief....

1.  New: Users-moderated list
2.  New: FreeS/WAN 2.02 released
3.  Recovering from short outages
4.  Opportunistic Encryption with X.509
5.  Neat stuff from the manual: "alsoflip="

 ------------------------------------------------------------------------------


1.  New: Users-moderated list
    =========================
    4 posts Sept 8 
    https://mj2.freeswan.org/cgi-bin/mj_wwwusr?user=&passw=&list=users&brief=on&func=archive-get-part&extra=200309/168

In response to the community's ongoing concerns about SPAM, freeswan.org 
listmaster Sam Sgro has set up an experimental users-moderated list. 
Sam writes:

  This list's moderation policy can be described as follows: posts
  will be removed if they do not appear to be from a sentient
  being attempting to knowingly communicate with FreeS/WAN users on
  a topic of mutual relevance.

He plans to use a combination of SpamAssassin and hand filtering to 
ensure that the posts to this list meet his criteria.

When Andrew Kohlsmith asked, "Isn't this exactly what the freeswan.ca 
FreeS/WAN users list does?", Sam responded that his methodology is slightly
different. Suspect posts are set aside for analysis, not automatically
filtered. Sam also remarked that the move might save Ken Bantoft of freeswan.ca
time and bandwidth.

Those who are interested may subscribe at:
https://lists.freeswan.org/cgi-bin/mj_wwwusr?user=&passw=&func=lists-long-full&extra=users-moderated



2.  New: FreeS/WAN 2.02 released
    =========================
    1 post Sept 4 
    https://mj2.freeswan.org/cgi-bin/mj_wwwusr?user=&passw=&list=users&brief=on&func=archive-get-part&extra=200309/94

FreeS/WAN 2.02 is out! It includes a few small improvements made this summer. 
Of note are:

* one-line configuration for initiator-only Opportunistic Encryption,
(OE) using ipsec.conf's new "myid" option. This greatly facilitates setup
for initiator-only OE. See doc/quickstart.html for more information on OE.
* a new RPM (Redhat Package Manager) spec file, to assist with compiling
RPMs from FreeS/WAN source.
* a bug fix which helps wavesec (http://www.wavesec.org) and OE coexist nicely.

Users running 2.01 should not need to upgrade unless they need one of these
improvements. Folks considering upgrading soon might want to wait for 2.03,
due within a month, in which we plan to include 2.6 compatibility code.
For Super FreeS/WAN users, 2.00 (beta) is available from 
http://www.freeswan.ca/code/super-freeswan/beta/ .

FreeS/WAN release announcements are sent to the FreeS/WAN users', design, 
and announce lists. Busy folks might want to subscribe directly to
[email protected].



3.  Recovering from short outages
    =============================
    4 posts Aug 21 - 26
    https://lists.freeswan.org/archives/2003-August/msg00408.html

When an internet connection goes down for a moment, it'd be nice not
to have to re-create all the IPsec tunnels which rely on it. Until recently, 
many people had to do that.

The problem: When the connection (and its associated IPsec-protected 
interface) goes down, its ipsecN virtual interface becomes detached.
Without the underlying interface, the Security Associations stored in 
FreeS/WAN's internal database cannot be applied, and new ones must be built. 

One way to handle this is to restart FreeS/WAN. However, recently, Sam Sgro 
explained a cleaner approach that works for 2.x. The key is a command like 
this one:

    ipsec tncfg --attach --virtual ipsec0 --physical ppp0

which reattaches an IPsec virtual interface to a newly restored physical 
interface. If the command succeeds, all FreeS/WAN's saved Security Associations
are re-applied to that interface, and FreeS/WAN recovers seamlessly.

D. Hugh Redelmeier has created an IPsec recovery script, available here,

http://lists.freeswan.org/pipermail/design/2002-July/003070.html

which you can tailor to your needs with a tnconfig (for 2.x) or restart (1.x) 
command.



4.  Opportunistic Encryption with X.509
    ===================================
    5 posts Aug 25 - 26
    https://mj2.freeswan.org/cgi-bin/mj_wwwusr?user=&passw=&list=users&brief=on&func=archive-get-part&extra=200308/521

When Ren? Matth?i asked:

    do you believe that such a configuration is possible with FreeS/WAN,
    esp. using X.509 certificates and some kind of "automatic" setup so that 
    a newly added LAN computer is integrated at once - provided there is 
    already a X.509 PKI [public key infrastructure] for all users?

Andreas Steffen responded that it is already easy to do this with a star
topology, and gave instructions. He added:

    If you want a full mesh, where each client talks directly to its
    peer over a tunnel then automatic setup of all tunnels (or better
    of those tunnels only that are really used) is not supported yet.

    I call this feature Opportunistic Encryption based on X.509
    certificates (OE-X.509) and it should be programmed around the
    existing OE support but must avoid the DNS lookup for the public keys.

This would be very handy for the many FreeS/WAN-X.509 users. It might also 
be possible to combine OE and X.509 in different ways, e.g. allowing FreeS/WAN
to accept certificates either from a local PKI or from a DNS lookup. 
About implementing OE-X.509, Andreas added:

    A guy from SuSE had a look this solution a couple of months ago and
    found that suppressing the DNS lookups is not so straightforward but
    could be done in principle.

We look forward to future developments in this area.



5.  Neat stuff from the manual: alsoflip
    ====================================
    http://www.freeswan.org/freeswan_trees/freeswan-2.02/doc/manpage.d/ipsec.conf.5.html

As you may know, ipsec.conf's "also" directive allows you to include one
connection description ("conn") as part of another. This shorthand is useful
for information common to a gateway and its subnets. As of FreeS/WAN 2.00, 
this is accompanied by "alsoflip", which allows you to to reverse the 
orientation of an included connection. From man ipsec.conf:

    also     the value is a section name; the parameters of that section 
             are appended to this section, as if they had been written as 
             part of it........

    alsoflip can be used in a conn section. It acts like an also that 
             flips the referenced section's entries left-for-right.

To network a group of non-OE capable machines, simply create a file containing
right-side conns for each. Reference this file via an "include" in ipsec.conf.
These pieces are now available as building blocks for your ipsec.conf conns.
Sample ipsec.conf entry:

	conn me-to-you
		alsoflip=me
		also=you

....and in the included file...

	conn me
		right=XXX.XXX.XXX.XXX
		rightsubnet=XXX.....
		rightrsasigkey=aQ.....
		etc.

	conn you
		right=YYY.YYY.YYY.YYY
		rightrsasigkey=aQ.....

You can even automate the creation of the ipsec.conf entries with a simple 
script.

Of course, if all machines had DNS entries set up for OE (as described in
doc/quickstart.html), far less configuration would be required.


 ------------------------------------------------------------------------------
lists.freeswan.org Email Summary                          Tuesday, Sept 9, 2003

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBP16jDXDIYXPDEHodAQF50QP+I3X/kWSkyzhG3bP6hAaDHWXpkGb739/W
bZqpI9TJRGb8fbMEZEFLAfFyqye9NekFo2oJJHt5PAZUiuVZT7hHwSvaC84Ww913
RRMxQKKndhlhUZUI2UUTWTHHH7o16xane8o4TVHZAYIaXtUsNPR7sj8Y7o7zwN97
oDP/GUjpHqY=
=zlWl
-----END PGP SIGNATURE-----