readme

ike协商阶段证书认证补丁 for freeswan

please refer to section 7.2.

If you don't want to mess with subjectAltNames, you can use the certificate's
Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN
and which can be written e.g. in the LDAP-type format

conn rw
     right=%any
     leftid="C=CH, O=strongSec GmbH, CN=pulpo.strongsec.com"

Since the subject's DN is part of the certificate, the leftid does not have to
be declared explicitly. Thus the entry

conn rw
     right=%any

automatically assumes the subject DN of leftcert to be the host ID.


4.2 Multiple certificates
    ---------------------

The X.509 patch supports multiple local host certificates and corresponding
RSA private keys:

conn rw1
     right=%any
     rightid=@peer1.domain1
     leftcert=myCert1.pem
     # leftid is DN of myCert1

conn rw2
     right=%any
     rightid=@peer2.domain2
     leftcert=myCert2.pem
     # leftid is DN of myCert2

When peer1 initiates a connection then FreeS/WAN will send myCert1 and will
sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas
myCert2 and myKey2 will be used in a connection setup started from peer2.


4.3 Configuring the peer side using CA certificates
    -----------------------------------------------

Now we can proceed to define our connections. In many applications we might
have dozens of mostly Windows-based road warriors connecting to a central
FreeS/WAN security gateway. The following most simple statement:

conn rw
     right=%any

defines the general roadwarrior case. The line right=%any literally means that
any IPSec peer is accepted, regardless of its current IP source address and its
ID, as long as the peer presents a valid X.509 certificate signed by a CA the
FreeS/WAN security gateway puts explicit trust in. Additionally the signature
during IKE main mode gives proof that the peer is in possession of the private
RSA key matching the public key contained in the transmitted certificate.

The ID by which a peer is identifying itself during IKE main mode can by any of
the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first
three ID types is used, then the accompanying X.509 certificate of the peer
must contain a matching subjectAltName field of the type ipAddress (IP:),
dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type
DER_ASN1_DN the identifier must completely match the subject field of the
peer's certificate. One of the two possible representations of a
Distinguished Name (DN) is the LDAP-type format

     rightid="C=CH, O=strongSec GmbH, CN=wroclaw.strongsec.com"

Additional whitespace can be added everywhere as desired since it will be
automatically eliminated by the X.509 parser. An exception is the single
whitespace between individual words , like e.g. in strongSec GmbH, which is
preserved by the parser.

The Relative Distinguished Names (RDNs) can alternatively be separated by a
slash '/' instead of a comma ','

     rightid="/C=CH/O=strongSec GmbH/CN=wroclaw.strongsec.com"

This is the representation extracted from the certificate by the OpenSSL
command line option

     openssl x509 -in wroclawCert.pem -noout -subject

The following RDNs are supported by the X.509 patch

+-----------------------------------------------+
| DC           Domain Component                 |
|-----------------------------------------------|
| C            Country                          |
|-----------------------------------------------|
| ST           State or province                |
|-----------------------------------------------|
| L            Locality or town                 |
|-----------------------------------------------|
| O            Organisation                     |
|-----------------------------------------------|
| OU           Organisational Unit              |
|-----------------------------------------------|
| CN           Common Name                      |
|-----------------------------------------------|
| ND           NameDistinguisher, used with CN  |
|-----------------------------------------------|
| N            Name                             |
|-----------------------------------------------|
| G            Given name                       |
|-----------------------------------------------|
| S            Surname                          |
|-----------------------------------------------|
| I            Initials                         |
|-----------------------------------------------|
| T            Personal title                   |
|-----------------------------------------------|
| E            E-mail                           |
|-----------------------------------------------|
| Email        E-mail                           |
|-----------------------------------------------|
| emailAddress E-mail                           |
|-----------------------------------------------|
| SN           Serial number                    |
|-----------------------------------------------|
| serialNumber Serial number                    |
|-----------------------------------------------|
| D            Description                      |
|-----------------------------------------------|
| ID           X.500 Unique Identifier          |
|-----------------------------------------------|
| UID          User ID                          |
|-----------------------------------------------|
| TCGID        [Siemens] Trust Center Global ID |
+-----------------------------------------------+

With the roadwarrior connection definition listed above, an IPsec SA for
the FreeS/WAN security gateway pulpo.strongsec.com itself can be established.
If any roadwarrior should be able to reach e.g. the two subnets 10.0.1.0/24
and 10.0.3.0/24 behind the security gateway then the following connection
definitions will make this possible

conn rw1
     right=%any
     leftsubnet=10.0.1.0/24

conn rw3
     right=%any
     leftsubnet=10.0.3.0/24

If not all peers in possession of a X.509 certificate signed by a specific
certificate authority shall be given access to the Linux security gateway,
then either a subset of them can be barred by listing the serial numbers of
their certificates in a certificate revocation list (CRL) as specified in
section 5.2 or as an alternative, access can be controlled by explicitly
putting a roadwarrior entry for each eligible peer into ipsec.conf:

conn soggy
     right=%any
     rightid=@soggy.strongsec.com

conn ewa
     right=%any
     rightid=[e-mail]

conn wroclaw
     right=%any
     rightid="C=CH, O=strongSec GmbH, CN=wroclaw.strongsec.com"

When the IP address of a peer is known to be stable, it can be specified as
well. This entry is mandatory when the FreeS/WAN host wants to act as the
initiator of an IPSec connection.

conn soggy
     right=160.85.22.3
     rightid=@soggy.strongsec.com

conn ewa
     right=160.85.22.8
     rightid=[e-mail]

conn wroclaw
     right=160.85.22.8
     rightid="C=CH, O=strongSec GmbH, CN=wroclaw.strongsec.com"

conn frosch
     right=160.85.22.5

In the last example the ID types FQDN, USER_FQDN, DER_ASN1_DN and IPV4_ADDR,
respectively, were used. Of course all connection definitions presented so far
have included the lines in the conn %defaults section, comprising among other
a left and leftcert entry, as well as a  rightrsasigkey parameter set to the
magic value %cert , signifying that the public key will be extracted from a
X.509 certificates sent by the peer.


4.4 Handling Virtual IPs and wildcard subnets
    -----------------------------------------

Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes
the inner IP source address of an IPsec tunnel to be different from the
outer IP source address usually assigned dynamically by the ISP.
Whereas the varying outer IP address can be handled by the right=%any
construct, the inner IP address or subnet must always be declared in a
connection definition. Therefore for the three roadwarriors rw1 to rw3
connecting to a FreeS/WAN security gateway the following entries are
required in /etc/ipsec.conf:

conn rw1
     right=%any
     righsubnet=10.0.1.5/32

conn rw2
     right=%any
     rightsubnet=10.0.1.5.47/32

conn rw3
     right=%any
     rightsubnet=10.0.1.128/28

With the wildcard parameter rightsubnetwithin these three entries can be
reduced to the single connection definition

conn rw
     right=%any
     rightsubnetwithin=10.0.1.0/24

Any host will be accepted (of course after successful authentication based on
the peer's X.509 certificate only) if it declares a client subnet lying totally
within the brackets defined by the wildcard subnet definition (in our example
10.0.1.0/24). For each roadwarrior a connection instance tailored to the
subnet of the particular client will be created,based on the generic
rightsubnetwithin template.

This feature of the X.509 patch can also be helpful with VPN clients getting a
dynamically assigned inner IP from a DHCP server located on the NAT router box.


4.5 Protocol and Port Selectors
    ---------------------------

The X.509 patch has been combined with the selectors patch to offer the
possibility to restrict the protocol and optionally the ports in an IPsec
SA using the rightprotoport and leftprotoport parameter. Some examples:

conn icmp
     right=%any
     rightprotoport=icmp
     left=%defaultroute
     leftid=@pluto.strongsec.com
     leftprotoport=icmp

conn http
     right=%any
     rightprotoport=6
     left=%defaultroute
     leftid=@pluto.strongsec.com
     leftprotoport=6/80

conn l2tp       # with port wildcard for Mac OS X Panther interoperability
     right=%any
     rightprotoport=17/%any
     left=%defaultroute
     leftid=@pluto.strongsec.com
     leftprotoport=17/1701

conn dhcp
     right=%any
     rightprotoport=udp/bootpc
     left=%defaultroute
     leftid=@pluto.strongsec.com
     leftsubnet=0.0.0.0/0  #allows DHCP discovery broadcast
     leftprotoport=udp/bootps
     rekey=no
     keylife=20s
     rekeymargin=10s
     auto=add

Protocols and ports can be designated either by their numerical values
or by their acronyms defined in /etc/services.

    ipsec auto --status

shows the following connection definitions:

"icmp": 160.85.106.10[@pulpo.strongsec.com]:1/0...%any:1/0
"http": 160.85.106.10[@pulpo.strongsec.com]:6/80...%any:6/0
"l2tp": 160.85.106.10[@pulpo.strongsec.com]:17/1701...%any:17/%any
"dhcp": 0.0.0.0/0===160.85.106.10[@pulpo.strongsec.com]:17/67...%any:17/68

Based on the protocol and port selectors appropriate eroutes will be set
up, so that only the specified payload types will pass through the IPsec
tunnel.


4.6 IPsec policies based on wildcards
    ---------------------------------

In large VPN-based remote access networks there is often a requirement that
access to the various parts of an internal network must be granted selectively,
e.g. depending on the group membership of the remote access user. Version 0.9.24
of the X.509 patch makes this possible by applying wildcard filtering on the
VPN user's distinguished name (ID_DER_ASN1_DN).

Let's make a practical example:
 
An organization has a sales department (OU=Sales) and a research group
(OU=Research). In the company intranet there are separate subnets for Sales
(10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web
server (10.0.2.100). The VPN clients use Virtual IP addresses that are either
assigned statically or via DHCP-over-IPsec. The sales and research departments
use IP addresses from separate DHCP address pools (10.1.0.0/24) and (10.1.1.0/24),