diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 3091 |
1 files changed, 3091 insertions, 0 deletions
@@ -0,0 +1,3091 @@ + ---------------------------- + strongSwan - Configuration + ---------------------------- + + +Contents +-------- + + 1. Overview + 2. Quickstart + 2.1 Site-to-Site case + 2.2 Host-to-Host case + 2.3 Four Tunnel case + 2.4 Four Tunnel case the elegant way with source routing + 2.5 Roadwarrior case + 2.6 Roadwarrior case with virtual IP + 3. Generating X.509 certificates and CRLs with OpenSSL + 3.1 Generating a CA certificate + 3.2 Generating a host or user certificate + 3.3 Generating a CRL + 3.4 Revoking a certificate + 4. Configuring the connections - ipsec.conf + 4.1 Configuring my side + 4.2 Multiple certificates + 4.3 Configuring the peer side using CA certificates + 4.4 Handling Virtual IPs and wildcard subnets + 4.5 Protocol and port selectors + 4.6 IPsec policies based on wildcards + 4.7 IPsec policies based on CA certificates + 4.8 Sending certificate requests + 4.9 IPsec policies based on group attributes + 5. Configuring certificates and CRLs + 5.1 Installing CA certificates + 5.2 Installing optional Certificate Revocation Lists (CRLs) + 5.3 Dynamic update of certificates and CRLs + 5.4 Local caching of CRLs + 5.5 Online Certificate Status Protocol (OCSP) + 5.6 CRL policy + 5.7 Configuring the peer side using locally stored certificates + 6. Configuring the private keys - ipsec.secrets + 6.1 Loading private key files in PKCS#1 format + 6.2 Entering passphrases interactively + 6.3 Multiple private keys + 7. Configuring CA properties - ipsec.conf + 8. Smartcard support + 8.1 Configuring a smartcard-based connection + 8.2 Entering the PIN code + 8.3 PIN-pad equipped smartcard readers + 8.4 Configuring a smartcard using pkcs15-init + 8.5 PKCS#1 proxy functions + 9. Configuring the clients + 9.1 strongSwan + 9.2 PGPnet + 9.3 Safenet/Soft-Remote + 9.4 SSH Sentinel + 9.5 Windows 2000/XP + 10. Monitoring functions + 11. Firewall support functions + 11.1 Environment variables in the updown script + 11.2 Automatic insertion and deletion of iptables firewall rules (NEW) + 11.3 Sample Linux 2.6 _updown_espmark script for iptables < 1.3.5 + 12. Authentication with raw RSA public keys + 13. Authentication with OpenPGP certificates + 13.1 OpenPGP certificates + 13.2 OpenPGP private keys + 13.3 Monitoring functions + 13.4 Suppression of certificate request messages + 14. Additional features + 14.1 Authentication and encryption algorithms + 14.2 NAT traversal + 14.3 Dead peer detection + 14.4 IKE Mode Config + 15. Copyright statement and acknowledgements + + +1. Overview + -------- + +strongSwan is an OpenSource IPsec solution for the Linux operating system +and currently supports the following features: + + * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels. + + * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption. + + * Authentication based on X.509 certificates or preshared secrets. + + * IPsec policies based on wildcards or intermediate CAs. + + * Powerful and flexible IPsec policies based on group attributes. + + * Retrieval of Certificate Revocation Lists (CRLs) via HTTP or LDAP. + + * Local caching of fetched CRLs + + * Full support of the Online Certificate Status Protocol (OCSP, RFC 2560). + + * CA management functions including OCSP and CRL URIs and default LDAP server. + + * Optional storage of RSA private keys on smartcards or USB crypto tokens + + * Standardized PKCS#11 interface with optional proxy functions serving + external applications (disc encryption, etc.). + + * NAT-Traversal (RFC 3947) + + * Support of Virtual IPs via static configuratin and IKE Mode Config + + * Support of Delete SA and informational Notification messages. + + * Dead Peer Detection (DPD, RFC 3706) + +Compatibility has successfully been tested with peers running the following +IPsec clients: + + FreeS/WAN, Openswan, SafeNet/SoftRemote, NCP Secure Entry Client, + SonicWALL Global VPN Client, The GreenBow, Microsoft Windows 2000/XP, etc. + +Furthermore, interoperability with the following VPN gateways +has been demonstrated during the IPsec 2001 Conference in Paris: + + Cisco IOS Routers, Cisco PIX firewall, Cisco VPN3000, + Nortel Contivity VPN Switch, NetScreen (FreeS/WAN as responder only), + OpenBSD with isakmpd, Netasq, Netcelo, and 6WIND. + +Potentially any IPsec implementation with X.509 certificate support can +be made to cooperate with strongSwan. The latest addition has been the successful +interoperability with the Check Point VPN-1 NG gateway. + + +2. Quickstart + ---------- + +In the following examples we assume for reasons of clarity that left designates +the local host and that right is the remote host. Certificates for users, hosts +and gateways are issued by a ficticious strongSwan CA. How to generate private keys +and certificates using OpenSSL will be explained in section 3. The CA certificate +"strongswanCert.pem" must be present on all VPN end points in order to be able to +authenticate the peers. + + +2.1 Site-to-site case + ----------------- + +In this scenario two security gateways moon and sun will connect the +two subnets moon-net and sun-net with each other through a VPN tunnel +set up between the two gateways: + + 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 + moon-net moon sun sun-net + +Configuration on gateway moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + left=%defaultroute + leftsubnet=10.1.0.0/16 + leftcert=moonCert.pem + right=192.168.0.2 + rightsubnet=10.2.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" + auto=start + +Configuration on gateway sun: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/sunCert.pem + + /etc/ipsec.secrets: + + : RSA sunKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + left=%defaultroute + leftsubnet=10.2.0.0/16 + leftcert=sunCert.pem + right=192.168.0.1 + rightsubnet=10.1.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +2.2 Host-to-host case + ----------------- + +This is a setup between two single hosts which don't have a subnet behind +them. Although IPsec transport mode would be sufficient for host-to-host +connections we will use the default IPsec tunnel mode. + + | 192.168.0.1 | === | 192.168.0.2 | + moon sun + +Configuration on host moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn host-host + left=%defaultroute + leftcert=moonCert.pem + right=192.168.0.2 + rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" + auto=start + +Configuration on host sun: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/sunCert.pem + + /etc/ipsec.secrets: + + : RSA sunKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn host-host + left=%defaultroute + leftcert=sunCert.pem + right=192.168.0.1 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +2.3 Four Tunnel case + ---------------- + +In a site-to-site setup a system administrator logged into the local gateway +often would like to access the peer gateway or a server in the subnet behind +the peer gateway over a secure IPsec tunnel.Since IP packets leaving a gateway +via the outer network interface carry the IP address of this NIC, four IPsec +Security Associations (SAs) must be set up to achieve full connectivity. The +example below shows how this can be done without much additional typing work , +using the "also" macro which includes connection definitions defined farther +down in the ipsec.conf file. + + 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 + moon-net moon sun sun-net + +Configuration on gateway moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + leftsubnet=10.1.0.0/16 + rightsubnet=10.2.0.0/16 + also host-host + + conn net-host + leftsubnet=10.1.0.0/16 + also host-host + + conn host-net + rightsubnet=10.2.0.0/16 + also host-host + + conn host-host + left=%defaultroute + leftcert=moonCert.pem + right=192.168.0.2 + rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" + auto=start + +Configuration on gateway sun: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/sunCert.pem + + /etc/ipsec.secrets: + + : RSA sunKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + leftsubnet=10.2.0.0/16 + rightsubnet=10.1.0.0/16 + also=host-host + + conn net-host + leftsubnet=10.2.0.0/16 + also=host-host + + conn host-net + rightsubnet=10.1.0.0/16 + also=host-host + + conn host-host + left=%defaultroute + leftcert=sunCert.pem + right=192.168.0.1 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +2.4 The four tunnel case the elegant way with source routing + -------------------------------------------------------- + +As you certainly agree, the full four tunnel case described in the previous +section becomes quite complex. If we could force the source address of the +IP packets leaving the gateway through the outer interface to take on the +IP address of the inner interface then we could use the single subnet-to-subnet +tunnel from section 2.1. Such a setup becomes possible if we use the +source routing capabilites of the ip route command that is already used +by strongSwan's updown scripts. + + 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 + moon-net moon sun sun-net + +If we assume that the inner IP address of gateway moon is 10.1.0.1 +and the inner IP address of gateway sun is 10.2.0.1 then the +insertion of the parameter + + leftsourceip=10.1.0.1 + +in the connection definition of moon and + + leftsourceip=10.2.0.1 + +on sun, respectively, will install source routing on both gateways. +As a result the command + + ping 10.2.0.1 + +executed on moon will leave the gateway with a source address of +10.1.0.1 and will therefore take the net-net IPsec tunnel. + +Configuration on gateway moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + left=%defaultroute + leftsourceip=10.1.0.1 + leftsubnet=10.1.0.0/16 + leftcert=moonCert.pem + right=192.168.0.2 + rightsubnet=10.2.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" + auto=start + +Configuration on gateway sun: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/sunCert.pem + + /etc/ipsec.secrets: + + : RSA sunKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn net-net + left=%defaultroute + leftsubnet=10.2.0.0/16 + leftsourceip=10.2.0.1 + leftcert=sunCert.pem + right=192.168.0.1 + rightsubnet=10.1.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +2.5 Roadwarrior case + ---------------- + +This is a very common case where a strongSwan gateway serves an arbitrary number +of remote VPN clients usually having dynamic IP addresses. + + 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | + moon-net moon carol + +Configuration on gateway moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn rw + left=%defaultroute + leftsubnet=10.1.0.0/16 + leftcert=moonCert.pem + right=%any + auto=add + +Configuration on roadwarrior carol: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/carolCert.pem + + /etc/ipsec.secrets: + + : RSA carolKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn home + left=%defaultroute + leftcert=carolCert.pem + right=192.168.0.1 + rightsubnet=10.1.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +2.6 Roadwarrior case with virtual IP + -------------------------------- + +Roadwarriors usually have dynamic IP addresses assigned by the ISP they are +currently attached to. In order to simplify the routing from moon-net back +to the remote access client carol it would be desirable if the roadwarrior had +an inner IP address chosen from a pre-assigned pool. + + 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1 + moon-net moon carol virtual IP + +This virtual IP address can be assigned to a strongSwan roadwarrior by adding +the parameter + + leftsourceip=10.3.0.1 + +to the roadwarrior's ipsec.conf. Of course the virtual IP of each roadwarrior +must be distinct. In our example it is chosen from the address pool + + rightsubnetwithin=10.3.0.0/16 + +which can be added to the gateway's ipsec.conf so that a single connection +definition can handle multiple roadwarriors. + +Configuration on gateway moon: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/moonCert.pem + + /etc/ipsec.secrets: + + : RSA moonKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn rw + left=%defaultroute + leftsubnet=10.1.0.0/16 + leftcert=moonCert.pem + right=%any + rightsubnetwithin=10.3.0.0/16 + auto=add + +Configuration on roadwarrior carol: + + /etc/ipsec.d/cacerts/strongswanCert.pem + + /etc/ipsec.d/certs/carolCert.pem + + /etc/ipsec.secrets: + + : RSA carolKey.pem "<optional passphrase>" + + /etc/ipsec.conf: + + conn home + left=%defaultroute + leftsourceip=10.3.0.1 + leftcert=carolCert.pem + right=192.168.0.1 + rightsubnet=10.1.0.0/16 + rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" + auto=start + + +3. Generating certificates and CRLs with OpenSSL + --------------------------------------------- + +This section is not a full-blown tutorial on how to use OpenSSL. It just lists +a few points that are relevant if you want to generate your own certificates +and CRLs for use with strongSwan. + + +3.1 Generating a CA certificate + --------------------------- + +The OpenSSL statement + + openssl req -x509 -days 1460 -newkey rsa:2048 \ + -keyout strongswanKey.pem -out strongswanCert.pem + +creates a 2048 bit RSA private key strongswanKey.pem and a self-signed CA +certificate strongswanCert.pem with a validity of 4 years (1460 days). + + openssl x509 -in cert.pem -noout -text + +lists the properties of a X.509 certificate cert.pem. It allows you to verify +whether the configuration defaults in openssl.cnf have been inserted correctly. + +If you prefer the CA certificate to be in binary DER format then the following +command achieves this transformation: + + openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der + +The directory /etc/ipsec.d/cacerts contains all required CA certificates either +in binary DER or in base64 PEM format. Irrespective of the file suffix, Pluto +"automagically" determines the correct format. + + +3.2 Generating a host or user certificate + ------------------------------------- + +The OpenSSL statement + + openssl req -newkey rsa:1024 -keyout hostKey.pem \ + -out hostReq.pem + +generates a 1024 bit RSA private key hostKey.pem and a certificate request +hostReq.pem which has to be signed by the CA. + +If you want to add a subjectAltName field to the host certificate you must edit +the OpenSSL configuration file openssl.cnf and add the following line in the +[ usr_cert ] section: + + subjectAltName=DNS:moon.strongswan.org + +if you want to identify the host by its Fully Qualified Domain Name (FQDN ), or + + subjectAltName=IP:192.168.0.1 + +if you want the ID to be of type IPV4_ADDR. Of course you could include both +ID types with + + subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1 + +but the use of an IP address for the identification of a host should be +discouraged anyway. + +For user certificates the appropriate ID type is USER_FQDN which can be +specified as + + subjectAltName=email:carol@strongswan.org + +or if the user's e-mail address is part of the subject's distinguished name + + subjectAltName=email:copy + +Now the certificate request can be signed by the CA with the command + + openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext + +If you omit the -days option then the default_days value (365 days) specified +in openssl.cnf is used. The -notext option avoids that a human readable +listing of the certificate is prepended to the base64 encoded certificate +body. + +If you want to use the dynamic CRL fetching feature described in section 4.7 +then you may include one or several crlDistributionPoints in your end +certificates. This can be done in the [ usr_cert ] section of the openssl.cnf +configuration file: + + crlDistributionPoints= @crl_dp + + [ crl_dp ] + + URI.1="http://crl.strongswan.org/strongswan.crl" + URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=Linux strongSwan + , c=CH?certificateRevocationList" + +If you have only a single http distribution point then the short form + + crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl" + +also works. Due to a known bug in OpenSSL this notation fails with ldap URIs. + +Usually a Windows-based VPN client needs its private key, its host or +user certificate, and the CA certificate. The most convenient way to load +this information is to put everything into a PKCS#12 file: + + openssl pkcs12 -export -inkey carolKey.pem \ + -in carolCert.pem -name "carol" \ + -certfile strongswanCert.pem -caname "strongSwan Root CA" \ + -out carolCert.p12 + + +3.3 Generating a CRL + ---------------- + +An empty CRL that is signed by the CA can be generated with the command + + openssl ca -gencrl -crldays 15 -out crl.pem + +If you omit the -crldays option then the default_crl_days value (30 days) +specified in openssl.cnf is used. + +If you prefer the CRL to be in binary DER format then this conversion +can be achieved with + + openssl crl -in crl.pem -outform DER -out cert.crl + +The directory /etc/ipsec.d/crls contains all CRLs either in binary DER +or in base64 PEM format. Irrespective of the file suffix, Pluto +"automagically" determines the correct format. + + +3.4 Revoking a certificate + ---------------------- + +A specific host certificate stored in the file host.pem is revoked with the +command + + openssl ca -revoke host.pem + +Next the CRL file must be updated + + openssl ca -gencrl -crldays 60 -out crl.pem + +The content of the CRL file can be listed with the command + + openssl crl -in crl.pem -noout -text + +in the case of a base64 CRL, or alternatively for a CRL in DER format + + openssl crl -inform DER -in cert.crl -noout -text + + + +4. Configuring the connections - ipsec.conf + ---------------------------------------- + +4.1 Configuring my side + ------------------- + +Usually the local side is the same for all connections. Therefore it makes +sense to put the definitions characterizing the strongSwan security gateway into +the conn %default section of the configuration file /etc/ipsec.conf. If we +assume throughout this document that the strongSwan security gateway is left and +the peer is right then we can write + +conn %default + # my side is left - the freeswan security gateway + left=%defaultroute + leftcert=moonCert.pem + # load connection definitions automatically + auto=add + +The X.509 certificate by which the strongSwan security gateway will authenticate +itself by sending it in binary form to its peers as part of the Internet Key +Exchange (IKE) is specified in the line + + leftcert=moonCert.pem + +The certificate can either be stored in base64 PEM-format or in the binary +DER-format. Irrespective of the file suffix, Pluto "automagically" determines +the correct format. Therefore + + leftcert=moonCert.der + +or + + leftcert=moonCert.cer + +would also be valid alternatives. + +When using relative pathnames as in the examples above, the certificate files +must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish +strongSwan's own certificates from locally stored trusted peer certificates +(see section 5.5 for details), they could also be stored in a subdirectory +below /etc/ipsec.d/certs as e.g. in + + leftcert=mycerts/moonCert.pem + +Absolute pathnames are also possible as in + + leftcert=/usr/ssl/certs/moonCert.pem + +As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain +Name (FQDN) of the form + +conn rw + right=%any + leftid=@moon.strongswan.org + +Important: When an FQDN identifier is used it must be explicitly included as a +so called subjectAltName of type dnsName (DNS:) in the certificate indicated +by leftcert. For details on how to generate certificates with subjectAltNames, +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=Linux strongSwan, CN=moon.strongswan.org" + +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 + --------------------- + +strongSwan 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 strongSwan 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 +strongSwan 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 +strongSwan 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=Linux strongSwan, CN=sun.strongswan.org" + +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 Linux strongSwan, 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=Linux strongSwan/CN=sun.strongswan.org" + +This is the representation extracted from the certificate by the OpenSSL +command line option + + openssl x509 -in sunCert.pem -noout -subject + +The following RDNs are supported by strongSwan + ++---------------------------------------------------+ +| 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 | +|---------------------------------------------------| +| unstructuredName Unstructured Name | +|---------------------------------------------------| +| UN Unstructured Name | +|---------------------------------------------------| +| employeeNumber Employee Number | +|---------------------------------------------------| +| EN Employee Number | ++---------------------------------------------------+ + +With the roadwarrior connection definition listed above, an IPsec SA for +the strongSwan security gateway moon.strongswan.org itself can be established. +If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24 +and 10.1.3.0/24 behind the security gateway then the following connection +definitions will make this possible + +conn rw1 + right=%any + leftsubnet=10.1.0.0/24 + +conn rw3 + right=%any + leftsubnet=10.1.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 sun + right=%any + rightid=@sun.strongswan.org + +conn carol + right=%any + rightid=carol@strongswan.org + +conn dave + right=%any + rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" + +When the IP address of a peer is known to be stable, it can be specified as +well. This entry is mandatory when the strongSwan host wants to act as the +initiator of an IPSec connection. + +conn sun + right=192.168.0.2 + rightid=@sun.strongswan.org + +conn carol + right=192.168.0.100 + rightid=carol@strongswan.org + +conn dave + right=192.168.0.200 + rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" + +conn venus + right=192.168.0.50 + +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. + + +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 strongSwan security gateway the following entries are +required in /etc/ipsec.conf: + +conn rw1 + right=%any + righsubnet=10.4.0.5/32 + +conn rw2 + right=%any + rightsubnet=10.4.0.47/32 + +conn rw3 + right=%any + rightsubnet=10.4.0.128/28 + +With the wildcard parameter rightsubnetwithin these three entries can be +reduced to the single connection definition + +conn rw + right=%any + rightsubnetwithin=10.4.0.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.4.0.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 strongSwan feature 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 + --------------------------- + +strongSwan offer the possibility to restrict the protocol and optionally the +ports in an IPsec SA using the rightprotoport and leftprotoport parameters. + +Some examples: + +conn icmp + right=%any + rightprotoport=icmp + left=%defaultroute + leftid=@moon.strongswan.org + leftprotoport=icmp + +conn http + right=%any + rightprotoport=6 + left=%defaultroute + leftid=@moon.strongswan.org + leftprotoport=6/80 + +conn l2tp # with port wildcard for Mac OS X Panther interoperability + right=%any + rightprotoport=17/%any + left=%defaultroute + leftid=@moon.strongswan.org + leftprotoport=17/1701 + +conn dhcp + right=%any + rightprotoport=udp/bootpc + left=%defaultroute + leftid=@moon.strongswan.org + 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 status + +shows the following connection definitions: + +"icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0 +"http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0 +"l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any +"dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]: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. strongSwan +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: + +conn sales + right=%any + rightid="C=CH, O=ACME, OU=Sales, CN=*" + rightsubnetwithin=10.1.0.0/24 # Sales DHCP range + leftsubnet=10.0.0.0/24 # Sales subnet + +conn research + right=%any + rightid="C=CH, O=ACME, OU=Research, CN=*" + rightsubnetwithin=10.1.1.0/24 # Research DHCP range + leftsubnet=10.0.1.0/24 # Research subnet + +conn web + right=%any + rightid="C=CH, O=ACME, OU=*, CN=*" + rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range + leftsubnet=10.0.2.100/32 # Web server + rightprotoport=tcp # TCP protocol only + leftprotoport=tcp/http # TCP port 80 only + +Of course group specific tunneling could be implemented on the +basis of the Virtual IP range specified by the rightsubnetwithin +parameter alone, but the wildcard matching mechanism guarantees that +only authorized user can access the corresponding subnets. + +The '*' character is used as a wildcard in relative distinguished names (RDNs). +In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain +the same number of RDNs (selected from the list in section 4.3) appearing in the +exact order defined by the template. + + "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson" + +matches the templates + + "C=CH, O=ACME, OU=Research, OU=*, CN=*" + + "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*" + + "C=CH, O=ACME, OU=*, OU=*, CN=*" + +but not the template + + "C=CH, O=ACME, OU=*, CN=*" + +which doesn't have the same number of RDNs. + + +4.7 IPsec policies based on CA certificates + --------------------------------------- + +As an alternative to the wildcard based IPsec policies described in section 4.6, +access to specific client host and subnets can abe controlled on the basis of +the CA that issued the peer certificate + + +conn sales + right=%any + rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA" + rightsubnetwithin=10.1.0.0/24 # Sales DHCP range + leftsubnet=10.0.0.0/24 # Sales subnet + +conn research + right=%any + rightca="C=CH, O=ACME, OU=Research, CN=Research CA" + rightsubnetwithin=10.1.1.0/24 # Research DHCP range + leftsubnet=10.0.1.0/24 # Research subnet + +conn web + right=%any + rightca="C=CH, O=ACME, CN=ACME Root CA" + rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range + leftsubnet=10.0.2.100/32 # Web server + rightprotoport=tcp # TCP protocol only + leftprotoport=tcp/http # TCP port 80 only + +In the example above, the connection "sales" can be used by peers +presenting certificates issued by the Sales CA, only. In the same way, +the use of the connection "research" is restricted to owners of certificates +issued by the Research CA. The connection "web" is open to both "Sales" and +"Research" peers because the required "ACME Root CA" is the issuer of the +Research and Sales intermediate CAs. If no rightca parameter is present +then any valid certificate issued by one of the trusted CAs in +/etc/ipsec.d/cacerts can be used by the peer. + +The leftca parameter usually doesn't have to be set explicitly because +by default it is set to the issuer field of the certificate loaded via +leftcert. The statement + + rightca=%same + +sets the CA requested from the peer to the CA used by the left side itself +as e.g. in + +conn sales + right=%any + rightca=%same + leftcert=mySalesCert.pem + + +4.8 Sending certificate requests + ---------------------------- + +The presence of a rightca parameter also causes the CA to be sent as +part of the certificate request message when strongSwan is the initiator. +A special case occurs when strongSwan responds to a roadwarrior. If several +roadwarrior connections based on different CAs are defined then all eligible +CAs will be listed in Pluto’s certificate request message. + + +4.9 IPsec policies based on group attributes + ---------------------------------------- + +X.509 attribute certificates are the most powerful mechanism for implementing +IPsec security policies. The rightgroups parameter in a connection definition +restricts the access to members of the listed groups only. An IPsec peer must +have a valid attribute certificate issued by a trusted Authorization Authority +and listing one of the requirede group attributes in order to get admitted. + +conn sales + right=%any + rightgroups="Sales" + rightsubnetwithin=10.1.0.0/24 # Sales DHCP range + leftsubnet=10.0.0.0/24 # Sales subnet + +conn research + right=%any + rightgroups="Research" + rightsubnetwithin=10.1.1.0/24 # Research DHCP range + leftsubnet=10.0.1.0/24 # Research subnet + +conn web + right=%any + rightgroups="Sales, Research" + rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range + leftsubnet=10.0.2.100/32 # Web server + rightprotoport=tcp # TCP protocol only + leftprotoport=tcp/http # TCP port 80 only + +In the examples above membership of the group "Sales" is required for +connection sales and membership of "Research" for connection research +whereas connection web is accessible for both groups. + +Currently the attribute certificates of the peers must be loaded statically +via the /etc/ipsec.d/acerts/ directory. In future releases of strongSwan it +will be possible to fetch them from an LDAP directory server. + + +5. Configuring certificates and CRLs + --------------------------------- + + +5.1 Installing the CA certificates + ------------------------------ + +X.509 certificates received by strongSwan during the IKE protocol are +automatically authenticated by going up the trust chain until a self-signed +root CA certificate is reached. Usually host certificates are directly signed +by a root CA, but strongSwan also supports multi-level hierarchies with +intermediate CAs in between. All CA certificates belonging to a trust chain +must be copied in either binary DER or base64 PEM format into the directory + + /etc/ipsec.d/cacerts/ + + +5.2 Installing optional certificate revocation lists (CRLs) + ------------------------------------------------------- + +By copying a CA certificate into /etc/ipsec.d/cacerts/, automatically all user +or host certificates issued by this CA are declared valid. Unfortunately +private keys might get compromised inadvertently or intentionally, personal +certificates of users leaving a company have to be blocked immediately, etc. +To this purpose certificate revocation lists (CRLs) have been created. CRLs +contain the serial numbers of all user or host certificates that have been +revoked due to various reasons. + +After successful verification of the X.509 trust chain, Pluto searches its +list of CRLs either obtained by loading them from the /etc/ipsec.d/crls/ +directory or fetching them dynamically from a HTTP or LDAP server for the +presence of a CRL issued by the CA that has signed the certificate. + +If the serial number of the certificate is found in the CRL then the public key +contained in the certificate is declared invalid and the IPSec SA will not be +established. If no CRL is found or if the deadline defined in the nextUpdate +field of the CRL has been reached, a warning is issued but the public key will +nevertheless be accepted. CRLs must be stored either in binary DER or base64 PEM +format in the crls directory. Section 7.3 will explain in detail how CRLs can +be created using OpenSSL. + + +5.3 Dynamic update of certificates and CRLs + --------------------------------------- + +Pluto reads certificates and CRLs from their respective files during system +startup and keeps them in memory in the form of chained lists. X.509 +certificates have a finite life span defined by their validity field. Therefore +it must be possible to replace CA or OCSP certificates kept in system memory +without disturbing established ISAKMP SAs. Certificate revocation lists should +also be updated in the regular intervals indicated by the nextUpdate field in +the CRL body. The following interactive commands allow the manual replacement +of the various files: + ++---------------------------------------------------------------------------+ +| ipsec rereadsecrets reload file /etc/ipsec.secrets | +|---------------------------------------------------------------------------| +| ipsec rereadcacerts reload all files in /etc/ipsec.d/cacerts/ | +|---------------------------------------------------------------------------| +| ipsec rereadaacerts reload all files in /etc/ipsec.d/aacerts/ | +|---------------------------------------------------------------------------| +| ipsec rereadocspcerts reload all files in /etc/ipsec.d/ocspcerts/ | +|---------------------------------------------------------------------------| +| ipsec rereadacerts reload all files in /etc/ipsec.d/acerts/ | +|---------------------------------------------------------------------------| +| ipsec rereadcrls reload all files in /etc/ipsec.d/crls/ | +|---------------------------------------------------------------------------| +| ipsec rereadall ipsec rereadsecrets | +| rereadcacerts | +| rereadaacerts | +| rereadocspcerts | +| rereadacerts | +| rereadcrls | +|---------------------------------------------------------------------------| +| ipsec purgeocsp purge the OCSP cache and fetching requests | ++---------------------------------------------------------------------------+ + +CRLs can also be automatically fetched from an HTTP or LDAP server by using +the CRL distribution points contained in X.509 certificates. The command + + ipsec listcrls + +shows any pending fetch requests: + + Oct 31 00:29:53 2002, trials: 2 + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + distPts: 'http://crl.strongswan.org/strongswan.crl' + 'ldap://ldap.strongswan.org/o=Linux strongSwan, c=CH + ?certificateRevocationList?base + ?(objectClass=certificationAuthority)' + +In the example above, an http and an ldap URL were extracted from a received +end certificate. An independent thread then tries to fetch a CRL from the +designated distribution points. The same thread also periodically checks +if any loaded CRLs are about to expire. The check interval can be defined in +the "config setup" section of the ipsec.conf file: + + config setup + crlcheckinterval=600 + +In our example the thread wakes up every 600 seconds or 10 minutes in order +to check the validity of the CRLs or to retry any pending fetch requests: + + List of X.509 CRLs: + + Dec 19 09:35:31 2002, revoked certs: 40 + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + distPts: 'http://crl.strongswan.org/strongswan.crl' + updates: this Dec 19 09:35:00 2002 + next Dec 19 10:35:00 2002 warning (expires in 19 minutes) + + List of fetch requests: + + Dec 19 10:15:31 2002, trials: 1 + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + distPts: 'http://crl.strongwan.org/strongswan.crl' + +The first trial to update a CRL is started 2*crlcheckinterval before the +nextUpdate time, i.e. when less than 20 minutes are left in our practical +example. When crlcheckinterval is set to 0 (this is also the default value +when the parameter is not set in ipsec.conf) then the CRL checking and updating +thread is not started and dynamic CRL fetching is disabled. + + +5.4 Local caching of CRLs + --------------------- + +The the ipsec.conf option + + config setup + cachecrls=yes + +activates the local caching of CRLs that were dynamically fetched from an +HTTP or LDAP server. Cached copies are stored in /etc/ipsec.d/crls under a +unique filename formed from the issuer's SubjectKeyIdentifier and the suffix .crl. + +With the cached copy the CRL is immediately available after pluto's startup. +When the local copy is about to expire it is automatically replaced with an +updated CRL fetched from one of the defined CRL distribution points. + + +5.5 Online Certificate Status Protocol (OCSP) + ----------------------------------------- + +The Online Certificate Status Protocol is defined by RFC 2560. It can be +used to query an OCSP server about the current status of an X.509 certificate +and is often used as a more dynamic alternative to a static Certificate +Revocation List (CRL). Both the OCSP request sent by the client and the OCSP +response messages returned by the server are transported via a standard +TCP/HTTP connection. Therefore cURL support must be enabled in pluto/Makefile: + + # Uncomment this line to enable OCSP fetching using HTTP + LIBCURL=1 + +In the simplest OCSP setup, a default URI under which the OCSP server for a +given CA can be accessed is defined in ipsec.conf: + + config setup + crlcheckinterval=600 + + ca strongswan + cacert=strongswanCert.pem + ocspuri=http://ocsp.strongswan.org:8880 + auto=add + +The HTTP port can be freely chosen. In our example we have assumed TCP port 8880. +The crlcheckinterval must be set to a value different from zero. Otherwise the +OCSP fetching thread will not be started. + +The well-known openssl-0.9.7 package from http://www.openssl.org implements +an OCSP server that can be used in conjunction with an openssl-based Public +Key Infrastructure. The OCSP client integrated into Pluto does not contain +any OpenSSL code though, but is based on the existing ASN.1 functionality of +strongSwan. + +The OpenSSL-based OCSP server is started with the following command: + + openssl ocsp -index index.txt -CA strongswanCert.pem -port 8880 \ + -rkey ocspKey.pem -rsigner ocspCert.pem \ + -resp_no_certs -nmin 60 -text + +The command consists of the parameters + + -index index.txt is a copy of the OpenSSL index file containing the list of + all issued certificates. The certificate status in indext.txt + is designated either by V for valid or R for revoked. If + a new certificate is added or if a certificate is revoked + using the openssl ca command, the OCSP server must be restarted + in order for the changes in index.txt to take effect. + + -CA the CA certificate + + -port the HTTP port the OCSP server is listening on. + +-rkey the private key used to sign the OCSP response. The use of the + sensitive CA private key is not recommended since this could + jeopardize the security of your production PKI if the OCSP + server is hacked. It is much better to generate a special + RSA private key just for OCSP signing use instead. + +-rsigner the certificate of the OCSP server containing a public key which + matches the private key defined by -rkey and which can be used by + the client to check the trustworthiness of the signed OCSP response. + +-resp_no_certs With this option the OCSP signer certificate defined by + -rsigner is not included in the OCSP response. + +-nmin the validity interval of an OCSP response given in minutes. + 2*crlcheckinterval before the expiration of the OCSP responses, + a new query will by pro-actively started by the Pluto fetching thread. + + If nmin is missing or set to zero then the default validity interval + compiled into Pluto will be 2 minutes, leading to a quasi one-time + use of the OCSP status response which will not be periodically + refreshed by the fetching thread. In conjunction with the parameter + setting "strictcrlpolicy=yes" a real-time certificate status query + can be implemented in this way. + +-text This option activates a verbose logging output, showing the contents + of both the received OCSP request and sent OCSP response. + +How does Pluto get hold of the OCSP signer certificate? There are two +possibilities: + +Either you put the OCSP certificate into the default directory + + /etc/ipsec.d/ocspcerts + +or alternatively Pluto can receive it as part of the OCSP response from the +remote OCSP server. In the latter case, how can Pluto make sure that +the server has indeed been authorized by the CA to deal out certificate status +information? In order to ascertain the OCSP signer capability, an extended +key usage attribute can be included in the OCSP server certificate. Just +insert the parameter + + extendedKeyUsage=OCSPSigner + +in the [ usr_cert ] section of your openssl.cnf configuration file before +the CA signs the OCSP server certificate. + +For a given CA the corresponding ca section in ipsec.conf (see section 7) allows +to define the URI of a single OCSP server. As an alternative an OCSP URI can be +embedded into each host and user certificate by putting the line + + authorityInfoAccess = OCSP;URI:http://ocsp.strongswan.org:8880 + +into the [ usr_cert ] section of your openssl.cnf configuration file. +If an OCSP authorityInfoAccess extension is present in a certificate then this +record overrides the default URI defined by the ca section. + + +5.6 CRL Policy + ---------- + +By default Pluto is quite tolerant concerning the handling of CRLs. It is not +mandatory for a CRL to be present in /etc/ipsec.d/crls and if the expiration +date defined by the nextUpdate field of a CRL has been reached just a warning +is issued but a peer certificate will always be accepted if it has not been +revoked. + +If you want to enforce a stricter CRL policy then you can do this by setting +the "strictcrlpolicy" option. This is done in the "config setup" section +of the ipsec.conf file: + + config setup + strictcrlpolicy=yes + ... + +A certificate received from a peer will not be accepted if no corresponding +CRL or OCSP response is available. And if an ISAKMP SA re-negotiation takes +place after the nextUpdate deadline has been reached, the peer certificate +will be declared invalid and the cached RSA public key will be deleted, causing +the connection in question to fail. Therefore if you are going to use the +"strictcrlpolicy=yes" option, make sure that the CRLs will always be updated +in time. Otherwise a total standstill would ensue. + +As mentioned earlier the default setting is "strictcrlpolicy=no" + + +5.7 Configuring the peer side using locally stored certificates + ----------------------------------------------------------- + +If you don't want to use trust chains based on CA certificates as proposed in +section 4.3 you can alternatively import trusted peer certificates directly +into Pluto. Thus you do not have to rely on the certificate to be transmitted +by the peer as part of the IKE protocol. + +With the conn %default section defined in section 4.1 and the use of the +rightcert keyword for the peer side, the connection definitions in section 4.3 +can alternatively be written as + + conn sun + right=%any + rightid=@sun.strongswan.org + rightcert=sunCert.cer + + conn carol + right=192.168.0.100 + rightcert=carolCert.der + +If the peer certificates are loaded locally then there is no sense in sending +any certificates to the other end via the IKE Main Mode protocol. Especially +if self-signed certificates are used which wouldn't be accepted any way by +the other side. In these cases it is recommended to add + + leftsendcert=never + +to the connection definition[s] in order to avoid the sending of the host's +own certificate. The default value is + + leftsendcert=always. + +If a peer certificate contains a subjectAltName extension, then an alternative +rightid type can be used, as the example "conn sun" shows. If no rightid +entry is present then the subject distinguished name contained in the +certificate is taken as the ID. + +Using the same rules concerning pathnames that apply to strongSwan's own +certificates, the following two definitions are also valid for trusted peer +certificates: + + rightcert=peercerts/carolCert.der + +or + + rightcert=/usr/ssl/certs/carolCert.der + + +6. Installing the private key - ipsec.secrets + ------------------------------------------ + +6.1 Loading private key files in PKCS#1 format + ------------------------------------------ + +Besides strongSwan's raw private key format strongSwan has been enabled to +load RSA private keys in the PKCS#1 file format. The key files can be +optionally secured with a passphrase. + +RSA private key files are declared in /etc/ipsec.secrets using the syntax + + : RSA <my keyfile> "<optional passphrase>" + +The key file can be either in base64 PEM-format or binary DER-format. The +actual coding is detected "automagically" by Pluto. The example + + : RSA moonKey.pem + +uses a relative pathname. In this case Pluto will look for the key file +in the directory + + /etc/ipsec.d/private + +As an alternative an absolute pathname can be given as in + + : RSA /usr/ssl/private/moonKey.pem + +In both cases make sure that the key files are root readable only. + +Often a private key must be transported from the Certification Authority +where it was generated to the target security gateway where it is going +to be used. In order to protect the key it can be encrypted with 3DES +using a symmetric transport key derived from a cryptographically strong +passphrase. + + openssl genrsa -des3 -out moonKey.pem 1024 + +Because of the weak security, key files protected by single DES will not +be accepted by Pluto!!! + +Once on the security gateway the private key can either be permanently +unlocked so that it can be used by Pluto without having to know a +passphrase + + openssl rsa -in moonKey.pem -out moonKey.pem + +or as an option the key file can remain secured. In this case the passphrase +unlocking the private key must be added after the pathname in +/etc/ipsec.secrets + + : RSA moonKey.pem "This is my passphrase" + +Some CAs distribute private keys embedded in a PKCS#12 file. Since Pluto +is not able yet to read this format directly, the private key part must +first be extracted using the command + + openssl pkcs12 -nocerts -in moonCert.p12 -out moonKey.pem + +if the key file moonKey.pem is to be secured again by a passphrase, or + + openssl pkcs12 -nocerts -nodes -in moonCert.p12 -out moonKey.pem + +if the private key is to be stored unlocked. + + +6.2 Entering passphrases interactively + ---------------------------------- + +On a VPN gateway you would want to put the passphrase protecting the private +key file right into /etc/ipsec.secrets as described in the previous paragraph, +so that the gateway can be booted in unattended mode. The risk of keeping +unencrypted secrets on a server can be minimized by putting the box into a +locked room. As long as no one can get root access on the machine the private +keys are safe. + +On a mobile laptop computer the situation is quite different. The computer can +be stolen or the user is leaving it unattended so that unauthorized persons +can get access to it. In theses cases it would be preferable not to keep any +passphrases openly in /etc/ipsec.secrets but to prompt for them interactively +instead. This is easily done by defining + + : RSA moonKey.pem %prompt + +Since strongSwan is usually started during the boot process, usually no +interactive console windows is available which can be used by Pluto to +prompt for the passphrase. This must be initiated by the user by typing + + ipsec secrets + +which actually is an alias for the existing command + + ipsec rereadsecrets + +and which causes the prompt + + need passphrase for '/etc/ipsec.d/private/moonKey.pem' + Enter: + +to appear. If the passphrase was correct and the private key file could be +successfully decrypted then + + valid passphrase + +results. Otherwise the prompt + + invalid passphrase, please try again + Enter: + +will give you another try. Entering a carriage return will abort the +the passphrase prompting. + + +6.3 Multiple private keys + --------------------- + +strongSwan supports multiple private keys. Since the connections defined +in ipsec.conf can find the correct private key based on the public key +contained in the certificate assigned by leftcert, default private key +definitions without specific IDs can be used + + : RSA myKey1.pem "<optional passphrase1>" + + : RSA myKey2.pem "<optional passphrase2>" + + +7. Configuring CA properties - ipsec.conf + -------------------------------------- + +Besides the definition of IPsec connections the ipsec.conf file can also +be used to configure a few properties of the certification authorities +needed to establish the X.509 trust chains. The following example shows +the parameters that are currently available: + + ca strongswan + cacert=strongswanCert.pem + ocspuri=http://ocsp.strongswan.org:8880 + crluri=http://crl.strongswan.org/strongswan.crl' + crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList" + ldaphost=ldap.strongswan.org + auto=add + +In a similar way as conn sections are used for connection definitions, an +arbitrary number of optional ca sections define the basic properties of CAs. + +Each ca section is named with a unique label + + ca strongswan + +The only mandatory parameter is + + cacert=strongswanCert.pem + +which points to the CA certificate which usually resides in the default +directory /etc/ipsec.d/cacerts/ but could also be retrieved via an absolute +path name. If the CA certificate is stored on a smartcard then the +notation + + cacert=%smartcard#<n> + +or alternatively + + cacert=%smartcard<optional slot nr>:<key id> + +can be used. The selection of smartcard slots is described in more detail +in section 8.1. + +From the certificate the CA's distinguished name and the serial number +is extracted. If an optional subjectKeyAuthentifier is present then it can +be used to uniquely identify consecutive generations of CA certificates +carrying the same distinguished name. + +The OCSP URI + + ocspuri=http://ocsp.strongswan.org:8880 + +allows to define an individual OCSP server per CA. Also up to two additional +CRL distribution points (CDPs) can be defined + + crluri=http://crl.strongswan.org/strongswan.crl' + crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList" + +which are added to any CDPs already present in the received certificates +themselves. The last parameter + + ldaphost=ldap.strongswan.org + +can be used to fill in the actual server name in LDAP CDPs where the host is missing +as e.g. in the crluri2 above. In future releases this ldaphost parameter might be used +to retrieve user, host and attribute certificates. + + +With the auto=add statement the ca definition is automatically loaded into Pluto during +system startup. Setting auto=ignore will ignore the ca section. Additional ca definitions +can be loaded from ipsec.conf during runtime with the command + + ipsec auto --type ca --add strongswan-sales + +and + + ipsec auto --type ca --delete strongswan-sales + +deletes the labeled ca entry. And finally the command + + ipsec auto --type ca --replace strongswan + +first deletes the old definition in Pluto's memory and then loads the updated version +from ipsec.conf. Any parameters which appear in several ca definitions can be put in +a common ca %default section + + ca %default + ldaphost=ldap.strongswan.org + + +8. Smartcard support + ----------------- + +8.1 Configuring a smartcard-based connection + ---------------------------------------- + +Defining a smartcard-based connection in ipsec.conf is easy: + + conn sun + right=192.168.0.2 + rightid=@sun.strongswan.org + left=%defaultroute + leftcert=%smartcard + auto=add + +In most cases there is a single smartcard reader or cryptotoken and only one +RSA private key safely stored on the crypto device. Thus usually the entry + + leftcert=%smartcard + +which stands for the full notation + + leftcert=%smartcard#1 + +is sufficient where the first certificate/private key object enumerated by +the PKCS#11 module is used. If several certificate/private key objects are +present then the nth object can be selected using + + leftcert=%smartcard#<n> + +The command + + ipsec listcards + +gives an overview over all certificate objects made available by the PKCS#11 +module.CA certificates are automatically available as trust anchors. + +As an alternative the certificate ID and/or the slot number defined by +the PKCS#11 standard can be specified using the notation + + leftcert=%smartcard<optional slot nr>:<key id in hex format> + +Thus + + leftcert=%smartcard:50 + +will look in all available slots for ID 0x50 starting with the first slot +(usually slot 0) whereas + + leftcert=%smartcard4:50 + +will directly check slot 4 (which is usually the first slot on the second +reader/token when using the OpenSC library) for a key with ID 0x50. + + +8.2 Entering the PIN code + --------------------- + +Since the smartcard signing operation needed to sign the hash with the +RSA private key during IKE Main Mode is protected by a PIN code, +the secret PIN must be made available to Pluto. + +For gateways that must be able to start IPsec tunnels automatically in +unattended mode after a reboot, the secret PIN can be stored statically +in ipsec.secrets + + : PIN %smartcard "12345678" + +or with the general notation + + : PIN %smartcard#<n> "<PIN code>" + +or alternatively + + : PIN %smartcard<optional slot nr>:<key id> "<PIN code>" + +On personal notebooks that could get stolen, you wouldn't want to store +your PIN in ipsec.secrets. Thus the alternative form + + : PIN %smartcard %prompt + +will prompt you for the PIN when you start up the first IPsec connection +using the command + + ipsec up sun + +The auto command calls the whack function which in turn communicates with +Pluto over a socket. Since the whack function call is executed from a command +window, Pluto can prompt you for the PIN over this socket connection. +Unfortunately roadwarrior connections which just wait passively for peers +cannot be initiated via the command window: + + conn rw + right=%any + left=%defaultroute + leftcert=%smartcard4:50 + auto=add + +But if there is a corresponding entry + + : PIN %smartcard4:50 %prompt + +in ipsec.secrets, then the standard command + + ipsec rereadsecrets + +or the alias + + ipsec secrets + +can be used to enter the PIN code for this connection interactively. + +The command + + ipsec listcards + +can be executed at any time to check the current status of the PIN code[s]. + + +8.3 PIN-pad equipped smartcard readers + ---------------------------------- + +Smartcard readers with an integrated PIN-pad offer an increased security +level because the PIN entry cannot be sniffed on the host computer e.g. +by a surrepticiously installed key logger. In order to tell pluto not to +prompt for the PIN on the host itself, the entry + + : PIN %smartcard:50 %pinpad + +can be used in ipsec.secrets. Because the key pad does not cache the PIN in +the smartcard reader, it must be entered for every PKCS #11 session login. +By default pluto does a session logout after every RSA signature. In order +to avoid the repeated entry of the PIN code during the periodic IKE main +mode rekeyings, the following parameter can be set in the config setup +section of ipsec.conf: + + config setup + pkcs11keepstate=yes + +The default setting is pkcs11keepstate=no. + + +8.4 Configuring a smartcard with pkcsc15-init + ----------------------------------------- + +strongSwan's smartcard solution is based on the PKCS#15 "Cryptographic Token +Information Format Standard" fully supported by OpenSC library functions. +Using the command + + pkcs15-init --erase-card --create-pkcs15 + +a fresh PKCS#15 file structure is created on a smartcard or cryptotoken. +With the next command + + pkcs15-init --auth-id 1 --store-pin --pin "12345678" --puk "87654321" + --label "my PIN" + +a secret PIN code with auth-id 1 is stored in an unretrievable location on +the smart card. The PIN will protect the RSA signing operation. If the PIN +is entered incorrectly more than three times the smartcard will be locked +and the PUK code can be used to unlock the card again. + +Next the RSA private key is transferred to the smartcard + + pkcs15-init --auth-id 1 --store-private-key myKey.pem [--id 45] + +By default the PKCS#15 smartcard record will be assigned the id 45. +Using the --id option multiple key records can be stored on a smartcard. + +At last we load the matching X.509 certificate onto the smartcard + + pkcs15-init --auth-id 1 --store-certificate myCert.pem [--id 45] + +The pkcs15-tool can now be used to verify the contents of the smartcard. + + pkcs15-tool --list-pins --list-keys --list-certificates + +If everything is ok then you are ready to use the generated PKCS#15 +structure with strongSwan. + +8.5 PKCS#11 proxy functions + ----------------------- + + With the setting pkcs11keepstate=yes some PKCS#11 implementations + (e.g. OpenSC) will lock the access to the smartcard as soon as pluto has + opened a session and will thus prevent other application from sharing the + smartcard resource. In order to solve this locking problem, strongSwan + offers a PKCS#11 proxy service making use of the whack socket communication + channel. The setting + + config setup + pkcs11proxy=yes + +will enable the proxy mode that is disabled by default. + +Currently two smartcard operations are supported: RSA encryption and +RSA decryption. The notation is as follows: + + ipsec scdecrypt <encrypted data> + [--inbase 16|hex|64|base64|256|text|ascii] + [--outbase 16|hex|64|base64|256|text|ascii] + [--keyid <id>] + +The default settings for inbase and outbase is hexadecimal. +Thus the simplest call has the form + + ipsec scdecrypt bb952b71920094ce0696ef9b8b26...12e6 + +and the returned result might be a decrypted 128 bit AES key + + 000 8836362e030e6707c32ffaa0bdad5540 + +The leading three characters represent the return code of the whack channel +with 000 signifying that no error has occured. Here is another example showing +the use of the inbase and outbase attributes + + ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text + +where the result has the form + + 000 This is a secret + +By default the first RSA private key found by the PKCS#11 enumeration is +used. If a different key should be selected then the notation introduced +in sections 8.1 and 8.2 can be used: + + --keyid %smartcard:50 + --keyid %smartcard4:50 + --keyid %smartcard#3 + +with --keyid %smartcard#1 being the default. If supported by the smartcard +and PKCS#11 library RSA encryption can be used with the notation + + ipsec scencrypt <plaintext data> + [--inbase 16|hex|64|base64|256|text|ascii] + [--outbase 16|hex|64|base64|256|text|ascii] + [--keyid <id>] + +with the example + + ipsec scencrypt "This is a secret" --inbase ascii --outbase 64 + +returning the expected output + + 000 m/ewDnTs0k...woE= + + +9. Configuring the clients + ----------------------- + +9.1 strongSwan + ---------- + +A strongSwan to strongSwan connection is symmetrical. Any of the four defined +ID types can be used, even different types on either end of the connection, +although this wouldn't make much sense. + ++--------------------------------------------------------------+ +| Connection Definition ID type subjectAltName | +|--------------------------------------------------------------| +| rightid (strongSwan) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | +|--------------------------------------------------------------| +| leftid (strongSwan) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | ++--------------------------------------------------------------+ + + +9.2 PGPnet + ------ + +Use the file peerCert.p12 to import PGPnet's X.509 certificate, the CA +certificate, plus the encrypted private key in binary PKCS#12 format into the +PGPkey tool. You will be prompted for the passphrase securing the private key. + +Use the file myCert.pem to import the X.509 certificate of the strongSwan +security gateway into the PGPkey tool. The PGPkeyTool does not accept X.509 +certificates in binary DER format, so it must be imported in base64 format: + + -----BEGIN CERTIFICATE----- + M... + + ... + -----END CERTIFICATE----- + +Make sure that there is no human-readable listing of the X.509 certificate in +front of the line + + -----BEGIN CERTIFICATE----- + +otherwise PGPnet will refuse to load the *.PEM file. Any surplus lines can +either be deleted by loading the certificate into a text editor or you can +apply the command + + openssl x509 -in myCert.pem -out myCert.pem + +to achieve the same effect. + +With authentication based on X.509 certificates, PGPnet always sends the ID +type DER_ASN1_DN, therefore rightid in the connection definition of the +strongSwan security gateway must be an ASN.1 distinguished name. + +In the receiving direction PGPnet accepts all four ID types from strongSwan. + ++--------------------------------------------------------------+ +| Connection Definition ID type subjectAltName | +|--------------------------------------------------------------| +| rightid (PGPnet) DER_ASN1_DN - | +|--------------------------------------------------------------| +| leftid (strongSwan) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | ++--------------------------------------------------------------+ + + +9.3 SafeNet/Soft-PK/Soft-Remote + --------------------------- + +SafeNet/Soft-PK and SafeNet/Soft-Remote can be configured to send their +identity either as DER_ASN1_DN, IPV4_ADDR, FQDN, or USER_FQDN. +In the receiving direction SafeNet/Soft-PK and SafeNet/Soft-Remote +accept all four ID types coming from strongSwan. + ++--------------------------------------------------------------+ +| Connection Definition ID type subjectAltName | +|--------------------------------------------------------------| +| rightid (SafeNet/Soft-PK) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | +|--------------------------------------------------------------| +| leftid (strongSwan) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | ++--------------------------------------------------------------+ + + +9.4 SSH Sentinel + ------------ + +SSH Sentinel sends its identity as DER_ASN1_DN if the subjectAltName field of +its certificate is empty. If a subjectAltName field is present, then the +corresponding type IPV4_ADDR, FQDN, or USER_FQDN is automatically chosen. +With several subjectAltName entries, the precedence of the different ID types +is not quite clear. In the receiving direction SSH Sentinel accepts all four +ID types from strongSwan. + ++--------------------------------------------------------------+ +| Connection Definition ID type subjectAltName | +|--------------------------------------------------------------| +| rightid (SSH Sentinel) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | +|--------------------------------------------------------------| +| leftid (strongSwan) DER_ASN1_DN - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | ++--------------------------------------------------------------+ + + +9.5 Windows 2000/XP + --------------- + +Windows 2000 and Windows XP always send the ID type DER_ASN1_DN, +therefore rightid in the connection definition of the strongSwan +security gateway must be an ASN.1 distinguished name.In the +receiving direction Windows 2000/XP accepts all four ID types +from strongSwan. + ++--------------------------------------------------------------+ +| Connection Definition ID type subjectAltName | +|--------------------------------------------------------------| +| rightid (Windows 2000/XP) DER_ASN1_DN - | +|--------------------------------------------------------------| +| leftid (strongSwan) DER_ASN1_D - | +| FQDN DNS: | +| USER_FQDN email: | +| IPV4_ADDR IP: | ++--------------------------------------------------------------+ + + +10. Monitoring functions + -------------------- + +strongSwan offers the following monitoring functions: + + + ipsec listalgs + +lists all IKE and ESP cryptographic algorithms that are currently +registered with strongSwan. + +The a listing has the following form: + + List of registered IKE Encryption Algorithms: + + #3 OAKLEY_BLOWFISH_CBC, blocksize: 64, keylen: 128-128-256 + #5 OAKLEY_3DES_CBC, blocksize: 64, keylen: 192-192-192 + #7 OAKLEY_AES_CBC, blocksize: 128, keylen: 128-128-256 + #65004 OAKLEY_SERPENT_CBC, blocksize: 128, keylen: 128-128-256 + #65005 OAKLEY_TWOFISH_CBC, blocksize: 128, keylen: 128-128-256 + #65289 OAKLEY_TWOFISH_CBC_SSH, blocksize: 128, keylen: 128-128-256 + + List of registered IKE Hash Algorithms: + + #1 OAKLEY_MD5, hashsize: 128 + #2 OAKLEY_SHA, hashsize: 160 + #4 OAKLEY_SHA2_256, hashsize: 256 + #6 OAKLEY_SHA2_512, hashsize: 512 + + List of registered IKE DH Groups: + + #2 OAKLEY_GROUP_MODP1024, groupsize: 1024 + #5 OAKLEY_GROUP_MODP1536, groupsize: 1536 + #14 OAKLEY_GROUP_MODP2048, groupsize: 2048 + #15 OAKLEY_GROUP_MODP3072, groupsize: 3072 + #16 OAKLEY_GROUP_MODP4096, groupsize: 4096 + #17 OAKLEY_GROUP_MODP6144, groupsize: 6144 + #18 OAKLEY_GROUP_MODP8192, groupsize: 8192 + + List of registered ESP Encryption Algorithms: + + #3 ESP_3DES, blocksize: 64, keylen: 168-168 + #7 ESP_BLOWFISH, blocksize: 64, keylen: 96-128 + #12 ESP_AES, blocksize: 128, keylen: 128-256 + #252 ESP_SERPENT, blocksize: 128, keylen: 128-256 + #253 ESP_TWOFISH, blocksize: 128, keylen: 128-256 + + List of registered ESP Authentication Algorithms: + + #1 AUTH_ALGORITHM_HMAC_MD5, keylen: 128-128 + #2 AUTH_ALGORITHM_HMAC_SHA1, keylen: 160-160 + #5 AUTH_ALGORITHM_HMAC_SHA2_256, keylen: 256-256 + #7 AUTH_ALGORITHM_HMAC_SHA2_512, keylen: 512-512 + + +The command + + ipsec listpubkeys [--utc] + +lists all public keys currently installed in the chained list of public +keys. These keys were statically loaded from ipsec.conf or aquired either +from received certificates or retrieved from secure DNS servers using +opportunistic mode. + +The public key listing has the following form: + + Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL, + until Sep 09 13:17:25 2009 ok + ID_FQDN '@moon.strongswan.org' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: '03' + Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL, + until Sep 09 13:17:25 2009 ok + ID_DER_ASN1_DN 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: '03' + Feb 11 13:36:53 2005, 2048 RSA Key AwEAAbgbh, + until Dec 31 22:43:18 2009 ok + ID_USER_FQDN 'carol@strongswan.org' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: '0a' + +It consists of + + - the date the public key was installed either in local time or UTC (--utc) + - the modulus size of the RSA key in bits + - a keyID consisting of 9 base64 symbols representing the public exponent + and the most significant bits of the modulus + - the expiration date of the public key (extracted from the certificate) + - the type and value of the ID associated with the public key. + - the issuer of the certificate the public key was extracted from. + - the serial number of the certificate the public key was extracted from. + +A public key can be associated with several IDs, e.g. using subjectAltNames +in certificates and an ID can possess several public keys, e.g. retrieved +from a secure DNS server. + + +The command + + ipsec listcerts [--utc] + +lists all local certificates, both strongSwan's own and those of +trusted peer loaded via leftcert and rightcert, respectively. + +The output has the form + + Feb 11 13:36:47 2005, count: 4 + subject: 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: 03 + pubkey: 2048 RSA Key AwEAAa+uL, has private key + validity: not before Sep 10 13:17:25 2004 ok + not after Sep 09 13:17:25 2009 ok + subjkey: e5:e4:10:87:6c:2a:c4:be:ad:85:49:42:a6:de:76:58:30:3a:9f:c1 + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + +and shows + + - the date the certificate was installed either in local time or UTC (--utc) + - the count shows how many connections refer to this certificate + - the subject of the certificate + - the issuer of the certificate + - the serial number of the certificate + - the size and keyid of the RSA public key contained in the certificate. + the label "has private key" indicates that a matching RSA private key + has been found, defined or loaded in ipsec.secrets. + - the label "on smartcard" indicates that the certificate was loaded from + a smartcard or cryptotoken and that most probably a matching RSA private + key also resides on-card. + - the validity of the CA certificate expressed either in local time or + UTC (--utc). The validity is checked automatically resulting either + in an "ok" message or a "fatal" error message. + - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash + over the certificate's public key. + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuer who signed the certificate. + - the serial number of the issuer's certificate. + + +The command + + ipsec listcacerts [--utc] + +lists all CA certificates that have been either been loaded from the directory +/etc/ipsec.d/cacerts/ or received via the IKE protocol. The output has the form + + Feb 11 13:36:52 2005, count: 1 + subject: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: 00 + pubkey: 2048 RSA Key AwEAAb/yX + validity: not before Sep 10 13:01:45 2004 ok + not after Sep 08 13:01:45 2014 ok + subjkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + +and shows + + - the date the CA certificate was installed either in local time or UTC (--utc) + - the count is always set to 1 + - the subject of the CA certificate + - the issuer of the CA certificate + - the serial number of the CA certificate + - the size and keyid of the RSA public key contained in the certificate. + - the validity of the CA certificate expressed either in local time or + UTC (--utc). The validity is checked automatically resulting either + in an "ok" message or a "fatal" error message. + - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash + over the CA certificate's public key. + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuer who signed the CA certificate. + For Root CA certificates the authorityKeyIdentifier and subjectKeyIdentifier + fields must be equal. + - the serial number of the issuer's certificate. + + +The command + + ipsec listaacerts [--utc] + +lists all Authorization Authority certificates that have been loaded from +the directory /etc/ipsec.d/aacerts/. +The output has the form + + Dec 20 13:29:55 2004, count: 1 + subject: 'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority' + issuer: 'C=CH, O=strongSec GmbH, CN=strongSec Root CA' + serial: 0f + pubkey: 2048 RSA Key AwEAAfazH + validity: not before Aug 24 13:41:56 2003 ok + not after Aug 23 13:41:56 2005 ok + subjkey: 56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90 + authkey: af:80:d5:c6:02:1c:96:78:b3:85:a5:65:a2:23:fd:ad:cf:e2:55:b2 + aserial: 00 + +and shows + + - the date the AA certificate was installed either in local time or UTC (--utc) + - the count is always set to 1 + - the subject of the AA certificate + - the issuer of the AA certificate + - the serial number of the AA certificate + - the size and keyid of the RSA public key contained in the certificate. + - the validity of the AA certificate expressed either in local time or + UTC (--utc). The validity is checked automatically resulting either + in an "ok" message or a "fatal" error message. + - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash + over the AA certificate's public key. + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuer who signed the AA certificate. + - the serial number of the issuer's certificate. + + +The command + + ipsec listocspcerts [--utc] + +lists all OCSO signer certificates that have been either loaded from +/etc/ipsec.d/ocspcerts/ or have been received included in the OCSP server +response. The output has the form + + Feb 09 22:56:17 2005, count: 1 + subject: 'C=CH, O=Linux strongSwan, OU=OCSP, CN=ocsp.strongswan.org' + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + serial: 09 + pubkey: 2048 RSA Key AwEAAaonT + validity: not before Nov 19 17:29:28 2004 ok + not after Nov 18 17:29:28 2009 ok + subjkey: 88:07:0a:b8:ae:c7:c1:07:5c:be:68:6a:c4:a5:7f:81:1f:37:b5:56 + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + +and shows + + - the date the OCSP signer certificate was installed either in local time + or UTC (--utc) + - the count is always set to 1 + - the subject of the OCSP signer certificate + - the issuer of the OCSP signer certificate + - the serial number of the OCSP signer certificate + - the size and keyid of the RSA public key contained in the certificate. + - the validity of the OCSP signer certificate expressed either in local time + or UTC (--utc). The validity is checked automatically resulting either + in an "ok" message or a "fatal" error message. + - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash + over the OCSP signer certificate's public key. + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuer who signed the OCSP certificate. + - the serial number of the issuer's certificate. + + +The command + + ipsec listacerts [--utc] + +lists all X.509 attribute certificates that have been loaded from the directory +/etc/ipsec.d/acerts/. +The output has the form + + Dec 20 13:29:56 2004 + holder: 'C=CH, O=strongSec GmbH, CN=Andreas Steffen' + hissuer: 'C=CH, O=strongSec GmbH, CN=strongSec Root CA' + hserial: 1e + groups: Research, Sales + issuer: 'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority' + serial: 2c + validity: not before Dec 19 14:51:38 2004 ok + not after Dec 20 14:51:38 2004 fatal (expired) + authkey: 56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90 + aserial: 0f + +and shows + + - the date the attribute certificate was installed either in local time + or UTC (--utc) + - the holder of the attribute certificate + - the issuer of holder's certificate + - the serial number of the holder's certificate + - the group attributes + - the issuing Authorization Authority of the attribute certificate + - the serial number of the attribute certificate + - the validity of the attribute certificate expressed either in local time or + UTC (--utc). The validity is checked automatically resulting either + in an "ok" message or a "fatal" error message. + - an authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuing Authorization Authority + - the serial number of the AA certificate. + + +The command + + ipsec listgroups [--utc] + +lists all group attributes either defined in right|leftgroups statements +in ipsec.conf or contained in loaded X.509 attribute certificates. +The output has the form + + Dec 20 13:29:55 2004, count: 4 + Research + Dec 20 13:30:04 2004, count: 1 + Research New York + Dec 20 13:29:55 2004, count: 3 + Sales + +and shows + + - the date the group attribute was first installed either in local time + or UTC (--utc) + - the count shows how many times the attribute is used + - the group name + + +The command + + ipsec listcainfos [--utc] + +lists the properties defined by the ca definition sections in ipsec.conf. +The output has the form + + Jun 08 22:31:37 2004, "strongswan" + authname: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + ldaphost: 'ldap.strongswan.org' + ocspuri: 'http://ocsp.strongswan.org:8880' + distPts: 'http://crl.strongswan.org/strongswan.crl' + 'ldap:///O=Linux strongSwan, C=CH?certificateRevocationList' + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + +and shows + + - the date the CA definition was loaded either in local time or UTC (--utc) + - the name of the ca section + - the distinguished name of the CA + - an optional default ldap host for the CA + - an optional OCSP URI + - a maximum of two optional CRL distribution points + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the CA. + - the serial number of the CA. + + +The command + + ipsec listcrls [--utc] + +lists all CRLs that have been loaded from /etc/ipsec.d/crls/. +The output has the form + + Feb 11 13:37:00 2005, revoked certs: 1 + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + distPts: 'http://crl.strongswan.org/strongswan.crl' + updates: this Feb 08 07:46:29 2005 + next Mar 10 07:46:29 2005 ok + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + +and shows + + - the date the CRL was installed either in local time or UTC (--utc) + - the number revoked certificates + - the issuer of the CRL + - the URLs of the distribution points where the CRL can be fetched from. + - the dates when the CRL was issued and when the next update + is expected, respectively, expressed either in local time or + UTC (--utc). It is automatically checked if the next update + deadline has passed, resulting either in an "ok" message, a + a "warning" message when strictcrlpolicy=no or a "fatal" message when + strictcrlpolicy=yes. + - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash + over the public key of the issuer who signed the CRL. This extension is + present in version 2 CRLs, only. + - the serial number of the issuer's certificate. + + +The command + + + ipsec listocsp [--utc] + +lists the contents of the OCSP response cache. The output has the form + + issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' + uri: 'http://ocsp.strongswan.org:8880' + authname: 13:9d:a0:9e:f4:32:ab:8f:e2:89:56:67:fa:d0:d4:e3:35:86:71:b9 + authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef + aserial: 00 + Feb 09 22:56:17 2005, until Feb 09 23:01:17 2005 warning (expires in 4 minutes) + serial: 0a, good + +and shows + + - the distinguished name of the CA handled by the OCSP server + - the http URI of the OCSP server. + - the 20 byte SHA-1 hash of the CA's distinguished name + - the 20 byte SHA-1 hash of the CA's public key + - the serial number of the CA's certificate + - a certificate status list showing + - the time the OCSP status was received + - an optional nextUpdate deadline (if missing the OCSP status will be + onetime with a lifetime of 2 minutes only). + - the serial number of the certificate + - the status of the certificate (good, revoked, unknown) + + +The command + + ipsec listcards [--utc] + +lists all smartcard records that are currently in use by Pluto. +The output has the form + + Aug 17 16:47:59 2005, #1, count: 6 + slot: 0, session closed, logged out, has valid pin + id: 45 + label: 'strongSwan' + subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org' + +with pkcs11keepstate=no and + + Aug 17 16:47:59 2005, #1, count: 6 + slot: 0, session opened, logged in, has pin pad + id: 45 + label: 'strongSwan' + subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org' + +with pkcs11keepstate=yes and shows + +- the date the certificate was read from the smartcard record +- the certificate objects are numbered starting from #1 +- the count shows how many connections and secret pin entries point + to the smartcard record +- the PKCS #11 slot number +- the PKCS #11 session state: closed | opened +- the PKCS #11 session login state: logged out | logged in +- the status of the PIN: no pin | valid pin | invalid pin | pin pad +- the ID of the certificate object +- the label of the certificate object +- the subject distinguished name of the certificate + + +The command + + ipsec auto --listall [--utc] + +is equivalent to + + ipsec listalgs + ipsec listpubkeys [--utc] + ipsec listcerts [--utc] + ipsec listcacerts [--utc] + ipsec listaacerts [--utc] + ipsec listocspcerts [--utc] + ipsec listacerts [--utc] + ipsec listgroups [--utc] + ipsec listcainfos [--utc] + ipsec listcrls [--utc] + ipsec listocsp [--utc] + ipsec listcards [--utc] + + +11. Firewall support functions + -------------------------- + + +11.1 Environment variables in the updown script + ------------------------------------------ + +strongSwan makes the following environment variables available +in the updown script indicated by the leftupdown option: + ++------------------------------------------------------------------+ +| Variable Example Comment | +|------------------------------------------------------------------| +| $PLUTO_PEER_ID carol@strongswan.org USER_FQDN (1) | +|------------------------------------------------------------------| +| $PLUTO_PEER_PROTOCOL 17 udp (2) | +|------------------------------------------------------------------| +| $PLUTO_PEER_PORT 68 bootpc (3) | +|------------------------------------------------------------------| +| $PLUTO_PEER_CA C=CH, O=ACME, CN=Sales CA (4) | +|------------------------------------------------------------------| +| $PLUTO_MY_ID @moon.strongswan.org FQDN (1) | +|------------------------------------------------------------------| +| $PLUTO_MY_PROTOCOL 17 udp (2) | +|------------------------------------------------------------------| +| $PLUTO_MY_PORT 67 bootps (3) | ++------------------------------------------------------------------+ + +(1) $PLUTO_PEER_ID/$PLUTO_MY_ID contain the IDs of the two ends + of an established connection. In our examples these + correspond to the strings defined by rightid and leftid, + respectively. + +(2) $PLUTO_PEER_PROTOCOL/$PLUTO_MY_PROTOCOL contain the protocol + defined by the rightprotoport and leftprotoport options, + respectively. Both variables contain the same protocol value. + The variables take on the value '0' if no protocol has been defined. + +(3) $PLUTO_PEER_PORT/$PLUTO_MY_PORT contain the ports defined by + the rightprotoport and leftprotoport options, respectively. + The variables take on the value '0' if no port has been defined. + +(4) $PLUTO_PEER_CA contains the distinguished name of the CA that + issued the peer's certificate. + + +11.2 Automatic insertion and deletion of iptables firewall rules + ----------------------------------------------------------- + +Starting with strongswan-2.7.0, the default _updown script automatically inserts +and deletes dynamic iptables firewall rules upon the establishment or teardown, +respectively, of an IPsec security association. This new feature is activated +with the line + + leftfirewall=yes + +and can be used when the following prerequisites are fulfilled: + + - Linux 2.4.x kernel, KLIPS IPsec stack, and arbitrary iptables version. + Filtering of tunneled traffic is based on ipsecN interfaces. + + - Linux 2.4.16 kernel or newer, native NETKEY IPsec stack, and + iptables-1.3.5 or newer. Filtering of tunneled traffic is based on + IPsec policy matching rules. + +If you define a local client subnet with a netmask larger than /32 behind +the gateway then the automatically inserted FORWARD iptables rules will +not allow to access the internal IP address of the host although it is +part of the client subnet definition. If you want additional INPUT and +OUTPUT iptables rules to be inserted, so that the host itself can be accessed +then add the following line: + + lefthostaccess=yes + +The _updown script also features a logging facility which will register the +creation (+) and the expiration (-) of each successfully established VPN +connection in a special syslog file in the following concise and easily +readable format: + +Jul 19 18:58:38 moon vpn: + + @carol.strongswan.org 192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16 +Jul 19 22:15:17 moon vpn: + - @carol.strongswan.org 192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16 + + +11.3 Sample Linux 2.6 updown script for iptables < 1.3.5 + --------------------------------------------------- + +If you are using a Linux 2.6 kernel older than 2.6.16 or an iptables version +older than 1.3.5 then the IPsec policy matching rules will not be available. +In order to make sure that only tunneled packets are accepted, a mark can be +set on incoming ESP packets. This "ESP" mark will be retained on the +decapsulated packet so that iptables rules inserted by the updown script can +check on the presence of this mark. For this purpose the template located in + + programs/_updown_espmark + +can be used. Store a copy of _updown_espmark e.g. in /etc/ipsec.updown and load +the script with the line + + leftupdown=/etc/updown.ipsec. + +In addition for the dynamic updown script to work the following static iptables rules +must be applied: + + iptables -t mangle -A INPUT -p 50 -j MARK --set-mark 50 + + +12. Authentication with raw RSA public keys + --------------------------------------- + +FreeS/WAN, as it is available from www.freeswan.org does public key +authentication with raw RSA public keys that are directly defined in +/etc/ipsec.conf + + rightrsasigkey=0sAq4c.... + +When version 1.x of standard FreeS/WAN receives a certificate request (CR), +it immediately drops the negotiation because it does not know how to answer +the request. As a workaround strongSwan does not send a CR if the RSA +key has been statically loaded using [right/left]rsasigkey. A problem +remains with roadwarriors initiating a connection. Since strongSwan +does not know the identity of the initiating peer in advance, it will always +send a CR, causing the rupture of the IKE negotiation if the peer is a +version 1.x FreeS/WAN host. To circumvent this problem the configuration +parameter 'nocrsend' can be set in the config setup section of /etc/ipsec.conf: + + config setup: + nocrsend=yes + +With this entry no certificate request is sent in any connection. +The default setting is nocrsend=no. + + +13. Authentication with OpenPGP certificates + ---------------------------------------- + +strongSwan also supports RSA based authentication using OpenPGP +certificates and OpenPGP V3 fingerprints used as an KEY_ID identifier. + + +13.1 OpenPGP certificates + -------------------- + +OpenPGP certificates containing RSA public keys can now directly be loaded +in ASCII armored PGP format using the leftcert and rightcert parameters +in /etc/ipsec.conf: + + conn pgp + right=%any + righcert=peerCert.asc + left=%defaultroute + leftcert=gatewayCert.asc + +The peer certificate must be stored locally (the default directory is +/etc/ipsec.d/certs) since currently no trust can be established for +PGP certificates received from a peer via the IKE protocol. + + +13.2 OpenPGP private keys + -------------------- + +PGP private keys in unencrypted form can now directly be loaded in ASCII +armored PGP format via an entry in /etc/ipsec.secrets: + + : RSA gatewayKey.asc + +Existing IDEA-encrypted RSA private keys can be unlocked with GnuPG and +the IDEA extension (see http://www.gnupg.org/gph/en/pgp2x.html) using +the commands + + gpg --import gatewayCert.asc + + gpg --allow-secret-key-import --import gatewayKey.asc + + gpg --edit-key <gateway ID> + > passwd #change to empty password + > save + + gpg -a --export-secret-key <gateway ID> gatewayKey.asc + + +13.3 Monitoring functions + -------------------- + +The command ipsec listcerts shows all loaded PGP certificates +in the following format: + + Aug 28 09:51:55 2002, count: 1 + fingerprint: 0x1ccfca12d93467ffa9d5093d87a465dc + pubkey: 1024 RSA Key ARHso6uKQ + created: Aug 27 08:51:39 2002 + until: --- -- --:--:-- ---- ok (expires never) + +The entries are + + - the date the certificate was loaded either in local time or UTC (--utc) + - the V3 fingerprint consisting of the 16 byte MD5 hash of the public key + which is used as an ID of type KEY_ID + - the modulus size of the RSA key in bits + - a keyID consisting of 9 base64 symbols representing the public exponent + and the most significant bits of the modulus + - the creation date of the public key (extracted from the certificate) + - the optional expiration date of the public key (extracted from the + certificate) + + +13.4 Suppression of certificate request messages + ------------------------------------------- + +PGPnet configured to work with OpenPGP certificates aborts the IKE +negotiation when it receives a X.509 certificate. Therefore it is recommended +(mandatory for roadwarrior connections) to set + + config setup: + nocrsend=yes + +in /etc/ipsec.conf. + + +14. Additional Features + ------------------- + + +14.1 Authentication and encryption algorithms + ---------------------------------------- + +strongSwan supports the following suite of encryption and authentication +algorithms for both IKE and ESP payloads. + ++------------------------------------------------------------------+ +| IKE algorithms (negotiated in Phase 1 Main Mode) | ++------------------------------------------------------------------+ +| Encryption algorithms: 3des, aes, serpent, twofish, blowfish | +|------------------------------------------------------------------| +| Hash algorithms: md5, sha, sha2 | +|------------------------------------------------------------------| +| DH groups: 1024, 1536, 2048, 3072, 4096, 6144, 8192 | ++------------------------------------------------------------------+ + +NOTE: For IKE the SHA-1 algorithm is denoted by "sha" + +The cryptographic IKE algorithms listed above are a fixed part of the +strongSwan distribution. Particular algorithms can be added or removed +in the "programs/pluto/alg" directory. + ++------------------------------------------------------------------+ +| ESP algorithms (negotiated in Phase 2 Quick Mode) | ++------------------------------------------------------------------+ +| Encryption algorithms: 3des, aes, serpent, twofish, blowfish | +|------------------------------------------------------------------| +| Hash algorithms: md5, sha1, sha2 | +|------------------------------------------------------------------| +| PFS groups: 1024, 1536, 2048, 3072, 4096, 6144, 8192 | ++------------------------------------------------------------------+ + +The cryptographic ESP algorithms listed above are a fixed part of the +strongSwan distribution. If your Linux 2.4 or 2.6 kernel includes the +CryptoAPI then additional ESP algorithms can be added or deleted as +kernel modules. + +The IKE and ESP cryptographic algorithms to be proposed to the peer +as an initiator can be specified on a per connection basis in the form + +conn normal + ... + ike=aes128-sha-modp1536,3des-sha-modp1536 + esp=aes128-sha1,3des-sha1 + ... + +or if you are more paranoid + +conn paranoid + ... + ike=aes256-sha2_512-modp2048 + esp=aes256-sha2_512 + ... + +If the the "ike" and "esp" configuration parameters are missing in +ipsec.conf, then the default settings + + ike=3des-md5-modp1536,3des-sha-modp1536,\ + 3des-md5-modp1024,3des-sha-modp1024 + esp=3des-md5,3des-sha1 + +arre implicitly assumed. The 3DES encryption algorithm and the MD5 and +SHA-1 hash algorithms are hardcoded into strongSwan and cannot be removed. + +If Perfect Forward Secrecy (PFS is desired), then a PFS group can be +optionally specified: + +conn make_sure + ... + pfs=yes + pfsgroup=modp2048,modp1536 + ... + +If the "pfs" parameter is missing then "pfs=yes" is assumed by default. +This means that PFS must be disabled explicitly by setting "pfs=no". + +If the "pfsgroup" parameter is missing then the default is + + pfsgroup=<Phase1 DH group> + +The "ike" and "esp" parameters are used to formulate one or several +transform proposals to the peer if the strongSwan VPN host is the initiator. +Attention! As a responder the first proposal from the peer is accepted that +is supported the by one of the registered algorithms listed by the command + + ipsec listalgs + +If the responder wants to restrict the allowed cipher suites the '!' flag +can be used to do so. The configuration + +conn normal_but_strict + ... + ike=aes128-sha-modp1536,3des-sha-modp1536! + esp=aes128-sha1,3des-sha1! + ... + +will only permit the listed algorithms defined above but no other methods +even if they might be supported by the responder. + + +14.2 NAT traversal + ------------- + +Currently please refer to README.NAT-Traversal document in the strongSwan +distribution. + + +14.3 Dead peer detection + -------------------- + +strongSwan implements the RFC 3706 Dead Peer Detection (DPD) keep-alive +scheme. If an established IPsec SA has been idle (i.e. without any traffic) +for N seconds (dpddelay=N) then strongSwan side sends a "hello" message +(R_U_THERE) and the peer replies with an acknowledge message (R_U_THERE_ACK). +If no response is received, the R_U_THERE messages are repeated until a DPD +timeout of M seconds (dpdtimeout=M) has elapsed. If still no traffic or +R_U_THERE_ACK packets were received, the peer is declared to be dead and all +SAs belonging to a common Phase 1 SA are deleted. + +DPD support is tuneable on a per connection basis by using the dpdaction, +dpddelay and dpdtimeout directives: + + conn roadwarrior + right=%any + left=%defaultroute + leftsubnet=10.1.0.0/16 + dpdaction=clear + + conn net-to-net + right=192.168.0.2 + rightsubnet=10.2.0.0/16 + left=%defaultroute + leftsubnet=10.1.0.0/16 + dpdaction=hold + dpddelay=60 + dpdtimeout=500 + +In the first example dpdaction=clear activates the DPD mechanism under the +condition that the peer supports RFC 3706. The values dpddelay=30s and +dpdtimeout=120s are assumed by default in the absence of these parameters, so +that during idle periods an R_U_THERE packet is sent every 30 seconds. If no +traffic or a no R_U_THERE_ACK packet is received from the peer within a +120 second time span, the peer will be declared dead and all SAs and associated +eroutes will be cleared. + +In the second example R_U_THERE packets are sent every 60 seconds and the +parameter setting dpdaction=hold will put the eroute of the ruptured connection +into a %trap state, so that when new outgoing traffic will occur, the +correspondig connection will be automatically renegotiated as soon as the +peer is up again. + +It is recommended to use dpdaction=hold for statically defined connections and +dpdaction=clear for dynamic roadwarrior connections. The default value is +dpdaction=none, which disables DPD. + + +14.4 IKE Mode Config + --------------- + +The IKE Mode Config protocol <draft-ietf-ipsec-isakmp-mode-cfg-04.txt> allows +the dynamic assignment of virtual IP addresses and optional DNS and WINS server +information to IPsec clients. Currently only "Mode Config Pull Mode" is +implemented where the client actively sends a Mode Config request to the server +in order to obtain a virtual IP. + +Client side configuration (carol): + + conn home + right=192.168.0.1 + rightsubnet=10.1.0.0/16 + rightid=@moon.strongswan.org + left=%defaultroute + leftsourceip=%modeconfig + leftcert=carolCert.pem + leftid=carol@strongswan.org + auto=start + +Server side configuration (moon): + + conn roadwarrior + right=%any + rightid=carol@strongswan.org + rightsourceip=10.3.0.1 + left=%defaultroute + leftsubnet=10.1.0.0/16 + leftcert=moonCert.pem + leftid=@moon.strongswan.org + auto=add + +The wildcard %modeconfig or %modecfg used in the leftsourceip parameter of the +client will trigger a Mode Config request. Currently the server will return +the virtual IP address defined by the rightsourceip parameter. In the future +an LDAP-based lookup mechanism will be supported. + + +15. Copyright statement and acknowledgements + ---------------------------------------- + + + FreeS/WAN version base system: + + Copyright (c) 1999-2004 + Henry Spencer, Richard Guy Briggs, + D. Hugh Redelmeier, Sandy Harris, Claudia Schmeing, + Michael Richardson, Angelos D. Keromytis, John Ioannidis, + + NAT-Traversal, ipsec starter, Delete SA and Notification messages: + + Copyright (c) 2002-2003, Mathieu Lafon + + Additional cryptoalgorithms (AES, etc): + + Copyright (c) 2002-2003, JuanJo Ciarlante + + Dead Peer Detection: + + Copyright (c) 2002-2004 + Ken Bantoft, JuanJo Ciarlante, Philip Craig, + Pawel Krawczyk, Srinvasan Venkataraman + + Porting to Linux 2.6 kernel: + + Copyright (c) 2003, Herbert Xu + + Dynamic CRL fetching: + + Copyright (c) 2002, Stephane Laroche + + IKE Mode Config protocol: + + Copyright (c) 2001-2002, Colubris Networks + + Virtual IP and source routing: + + Copyright (c) 2003, Tuomo Soini + + Port and protocol selectors for outbound traffic: + + Copyright (c) 2002, Stephen J. Bevan + + PGPnet-RSA parts of patch: + + Copyright (c) 2000, Kai Martius + + X.509, OCSP and smartcard functionality: + + Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann + Copyright (c) 2001, Marco Bertossa, Andreas Schleiss + Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser + Copyright (c) 2002, Martin Berner, Lukas Suter + Copyright (c) 2003, Christoph Gysin, Simon Zwahlen + Copyright (c) 2004, David Buechi, Michael Meier + Copyright (c) 2000-2005, Andreas Steffen + + Zurich University of Applied Sciences in Winterthur, Switzerland + + scepclient: + + Copyright (c) 2005, Jan Hutter, Martin Willi + Copyright (c) 2005-2006, Andreas Steffen + + University of Applied Sciences in Rapperswil, Switzerland + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. See http://www.fsf.org/copyleft/gpl.txt. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + for more details. +----------------------------------------------------------------------------- + +This file is RCSID $Id: README,v 1.33 2006/04/24 21:27:49 as Exp $ + |