readme

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

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 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