Re: Slicing and dicing

Dan.McDonald@Eng.Sun.Com (Dan McDonald) Fri, 12 September 1997 18:19 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08860 for ipsec-outgoing; Fri, 12 Sep 1997 14:19:39 -0400 (EDT)
From: Dan.McDonald@Eng.Sun.Com
Message-Id: <199709121828.LAA13256@kebe.eng.sun.com>
Subject: Re: Slicing and dicing
To: mcr@sandelman.ottawa.on.ca
Date: Fri, 12 Sep 1997 11:28:35 -0700
Cc: ipsec@tis.com
In-Reply-To: <199709121747.NAA26920@istari.sandelman.ottawa.on.ca> from "Michael C. Richardson" at Sep 12, 97 01:47:35 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

>   Given this, I'd say forget about handling it.

Quick question, do you mean key mgmt. failing?  If so, I agree, and you state
the perfect reasons why below...

>   The world isn't just DES, though. The question about what to do with weak
> keys in general. Are weak keys in other algorithms equally improbable?

I dunno about other algorithms, but you can't discount that possibility.

>   Given the difficulty in even test code to replace the weak keys with
> other keys, I'd prefer to simply fail the SA, and cause ISAKMP to start
> over again. I think even my vic-20 can afford to do this once every
> (86400/300 * 365)/(2* 10**-52) years.

Pardon the small plug, but PF_KEY has, since its inception, and at the
insistence of the many, REQUIRED to return errors when an algorithm's key is
deemed weak.  This means either SADB_ADD, or SADB_UPDATE will fail miserably
when/if a weak key is fed down.

I agree with Michael, in that the SA should fail, and ISAKMP should kick-in
again.

Just my $0.02.

Dan