[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(racoon 537) Re: [Ipsec-tools-devel] Re: authentication bug in KAME's racoon (fwd)
- To: Brian Buesker <bbuesker@qualcomm.com>
- Subject: (racoon 537) Re: [Ipsec-tools-devel] Re: authentication bug in KAME's racoon (fwd)
- From: Michal Ludvig <michal@logix.cz>
- Date: Tue, 15 Jun 2004 17:25:35 +0200 (CEST)
- Cc: ipsec-tools-devel@lists.sourceforge.net, racoon@kame.net
- Delivered-to: racoon-archive@kame.net
- Delivered-to: racoon-outgo@kame.net
- Delivered-to: racoon@orange.kame.net
- Delivered-to: racoon@kame.net
- In-reply-to: <40CF1166.2010106@qualcomm.com>
- References: <Pine.LNX.4.53.0406151433510.24770@maxipes.logix.cz> <Pine.LNX.4.53.0406151435080.24770@maxipes.logix.cz> <40CF1166.2010106@qualcomm.com>
- Reply-to: racoon@kame.net
- Sender: owner-racoon@kame.net
On Tue, 15 Jun 2004, Brian Buesker wrote:
> >Maybe we should allow self signed, expired and maybe also invalid purpose
> >ones certs if the cert is available locally in "peers_certfile"?
> >
> I agree with Ludo that we should have a strict option that fails on any
> of the above verification errors. However, I think strict should be the
> default to prevent compromises in the default configuration. A
> non-strict option should be specified if some of the above verification
> errors should allow the negotiation to continue. I think it would be
> acceptable to accept self-signed and maybe invalid purpose certs when
> the non-strict option is given and the cert is available locally. I'd
> caution against accepting expired certs since I think you'd still want
> them to fail even if the cert is available locally.
>
> >OTOH we may allow "unable to get CRL" when verifying certs obtained from
> >the payload.
> >
> I think this should probably be a configurable option. A CRL should be
> required in the strict mode since otherwise a compromised cert opens up
> everything. It'd probably be ok to allow no CRL when in the non-strict
> mode since some people may not want to generate a CRL for testing purposes.
Looks like it's the right time for 'x509_verify_flags' statement with a
list of allowed failures. E.g.
x509_verify_flags no_crl, self_signed, expired, other_purpose, [...];
Opinions?
Anyway, IPsec-tools 0.3.3 are out with the following behaviour:
It only allows (but still warns) that CRL for the cert is unavailable for
certificates obtained from the IKE payload. All other problems are treated
as errors and ISAKMP negotiation fails.
For locally available certs (via peers_certfile statement) the rules are
more relaxed and because the certificate can be trustfully verified it is
allowed that it is expired, self-signed or "for other puropse". The
verification still succeeds but emits a warning.
Thanks to Aidas for providing the patch!
Michal Ludvig
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal