freeswan.diff

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

+
+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),
+respectively. An X.509 certificate is issued to each employee, containing in its
+subject distinguished name the country (C=CH), the company (O=ACME),
+the group membership(OU=Sales or OU=Research) and the common name (e.g.
+CN=Bart Simpson).
+
+The IPsec policy defined above can now be enforced with the following three
+IPsec security associations:
+