freeswan.diff

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

+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 FreeS/WAN is the initiator.
+A special case occurs when FreeS/WAN responds to a roadwarrior. If several
+roadwarrior connections based on different CAs are defined then all eligible
+CAs will be listed in Pluto抯 certificate request message.
+
+
+5. Configuring certificates and CRLs
+   ---------------------------------
+
+
+5.1 Installing the CA certificates
+    ------------------------------
+
+X.509 certificates received by FreeS/WAN 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 the X.509 patch 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 auto --rereadsecrets    reload file /etc/ipsec.secrets              |
+|---------------------------------------------------------------------------|
+| ipsec auto --rereadcacerts    reload all files in /etc/ipsec.d/cacerts/   |
+|---------------------------------------------------------------------------|
+| ipsec auto --rereadocspcerts  reload all files in /etc/ipsec.d/ocspcerts/ |
+|---------------------------------------------------------------------------|
+| ipsec auto --rereadcrls       reload all files in /etc/ipsec.d/crls/      |
+|---------------------------------------------------------------------------|
+| ipsec auto --rereadall        ipsec auto --rereadsecrets                  |
+|                                          --rereadcacerts                  |
+|                                          --rereadocspcerts                |
+|                                          --rereadcrls                     |
+|---------------------------------------------------------------------------|
+| ipsec auto --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 auto --listcrls
+    
+shows any pending fetch requests:
+
+  Oct 31 00:29:53 2002, trials: 2
+         issuer:  'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
+         distPts: 'http://www.strongsec.com/ca/cert.crl'
+	          'ldap://ldap.strongsec.com/o=strongSec GmbH, 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=strongSec GmbH, CN=strongSec Root CA'
+         distPts: 'http://www.strongsec.com/ca/cert.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=strongSec GmbH, CN=strongSec Root CA'
+        distPts: 'http://www.strongsec.com/ca/cert.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 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 strongsec
+        cacert=caCert.pem
+        ocspuri=http://ocsp.strongsec.com: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
+the X.509 patch.
+    
+The OpenSSL-based OCSP server is started with the following command:
+    
+    openssl ocsp -index index.txt -CA cacert.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 憇trictcrlpolicy=yes