[Openswan Users] Openswan IPSec
Chen, Xuli (James)
chenja at avaya.com
Thu May 12 13:50:45 EDT 2011
Great thanks, Paul. Sorry for the tough questions. I'll follow your instructions to dig further.
From: Paul Wouters [mailto:paul at xelerance.com]
Sent: Thursday, May 12, 2011 12:45 PM
To: Chen, Xuli (James)
Cc: users at openswan.org
Subject: Re: Openswan IPSec
On Thu, 12 May 2011, Chen, Xuli (James) wrote:
> I’m using openswan-2.6.21_53 from redhat. I don’t know much about openswan design, but I have to answer if openswan meets all these
> requirements. Can you please help me? Appreciate you help.
> The system shall only support the following erroneous messages associated with a certificate request:
"only"? My guess is these map to various RFCs and their response codes. So your best bet would be to
check the source and look at openswan-2.6.X/include/ietf_constants.h
> Path Development and Path Processing:
> 1) Applications supporting relying party processes must be capable of developing a certificate path and processing the path (The
> path development process produces a sequence of certificates that connect a given end-entity certificate to a trust point).
If this refers to CAs and intermediate CAs, then yes.
> Path Development:
> 1) Applications should construct paths automatically without involvement of a human. [James: ?]
Yes. Though unlike TLS, the entire path is not sent AFAIK. So just ensure intermediate CAs are present in /etc/ipsec.d/cacerts/
> Path Processing :
> 1) Applications should reject a path where an included certificate expired between the effective date and the current date unless
> the application is re-verifying a signature that was verified at an earlier date when none of the involved certificates were expired
> [James: ?]
This does not make much sense to me. Why would you "re-verify" a signature.
Openswan will not re-use the cert for rekeying the IPsec SA, so expiration then is not noticed. However, when rekeying
the ISAKMP SA, it is of course re-checked.
> 2) When an application must validate a path involving expired certificates, the application must check the status of using CRLs
> issued after the effective date but prior to the expiration of a currently expired certificate and should use the most current CRL
> preceding a certificate’s expiration.[James: ?]
this seems wrong. If a CRL revokes a cert, it is revoked on next ISAKMP check. Whether the cert's signature is expired
or not is irrelevant.
> 3) Applications must perform the following major steps for path processing for each certificate in the chain:
> · Verifying certificate signatures. This verification shall use the certificate issuer’s public key. [James: yes.]
> · Ensuring effective date falls within the certificate’s validity period. [James: yes.]
> · Ensuring certificate use is consistent with extensions.[James: ?]
We might check some of those. I am not sure if we check all known extensions.
> Certificate Status Checking:
> 1) If using CRL for certificate status check, applications shall perform the following steps for each certificate being validated
> (target certificate):
> · Verify the signature on the CRL. This verification requires developing and processing a certificate path establishing that the
> target certificate’s issuer trusted the CRL issuer to issue CRLs. [James: openswan checks the issuer's signature of the crl]
> · Verify that the CRL has not expired if the target certificate has not expired.[James: yes.] A CRL is expired if the current date
> is after the CRL’s next update field value. (See above paragraph regarding paths with expired certificates.)[James:?] If the target
> certificate has expired, verify that the CRL’s issue date follows the effective date and precedes the certificate’s expiration
> date.[James: ?]
if the crl expired, it is either ignored or no one can login, depending on strictcrlpolicy=
> · Search the list of revoked certificates to determine that the target certificate either is not included or its revocation date
> is after the effective date. [James: yes.]
> Extension Processing:[James: ?]
> 1) Applications shall ensure that the intended use of the certificate is consistent with the extensions.
> 2) Applications must process the critical extensions and should process non-critical extensions.
not sure if we do all.
> 3) Applications shall ensure that in the Key Usage extension in the end-entity certificate:
> · The digital signature bit is set for authentication uses.
> · The non-repudiation bit is set for non-repudiation uses.
> · The key encipherment bit or the data encipherment bit is set for encryption uses depending on whether keys or data are to
> be encrypted.
I dont know by heart, check programs/pluto/x509.c ?
> 4) Applications shall ensure that for certificates other the Root CA in the Key Usage extension:
> · The Certificate Signature bit is set in the certificate containing the public key used to sign the next certificate in the
> · The CRL Signature bit is set in the certificate containing the public key used to sign a CRL.
Not sure what this means. We don't mandate CRL, but if the CA lists one, then we do require it I believe.
> 5) Applications shall ensure that Basic Constraints extension is true in the certificate containing a public key used to sign a
> subsequent certificate in the path.
More information about the Users