[70031] in North American Network Operators' Group
Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong
daemon@ATHENA.MIT.EDU (Paul Jakma)
Mon Apr 26 00:14:37 2004
Date: Mon, 26 Apr 2004 05:13:17 +0100 (IST)
From: Paul Jakma <paul@clubi.ie>
To: Sean Donelan <sean@donelan.com>
Cc: sthaug@nethelp.no, nanog@merit.edu
In-Reply-To: <Pine.GSO.4.58.0404241626410.10790@clifden.donelan.com>
Errors-To: owner-nanog-outgoing@merit.edu
On Sat, 24 Apr 2004, Sean Donelan wrote:
> Key management is still an issue. It would be nice to be able to
> "roll" the MD5 key change similar to more recent protocols. If you
> had a list of valid keys, we wouldn't need to perfectly synchronize
> key changes. But this would increase CPU utilization for failed
> packets, i.e. check key, key + 1, key - 1, increasing the DOS risk.
Or, gosh, just use IPSec in AH mode which solves this problem by
allowing one to use very strong public-key auth (rsa, x509 ssl certs,
etc..) or simple (pre-shared-keys + a variety of symmetric ciphers,
from weak to strong) for initial authentication and hence
negotiation of a session key to be used for per-packet auth/integrity
the md5 hack was invented as a simple stopgap until availability of
ipsec, why perpetuate the hack ever more? adding rekeying features
to tcp-md5, eek!
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
It is not enough to have great qualities, we should also have the
management of them.
-- La Rochefoucauld
