[Openswan Users] Openswan IPSec

[Chen, Xuli (James)]

Great thanks, Paul. Sorry for the tough questions. I'll follow your instructions to dig further.

Regards,
James

-----Original Message-----
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.]
> 
> I
> 
> ·        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):
> 
> I
> 
> ·        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]

yes.

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

unsure.

> I
> 
> 2)     Applications must process the critical extensions and should process non-critical extensions.

not sure if we do all.

> I
> 
> 3)     Applications shall ensure that in the Key Usage extension in the end-entity certificate:
> 
> I
> 
>      ·        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:
> 
> I
> 
>      ·        The Certificate Signature bit is set in the certificate containing the public key used to sign the next certificate in the
> chain.

yes

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

not sure.

Paul