Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5 key for old session after key change)
Paul Jakma
paul at clubi.ie
Mon Apr 26 04:13:17 UTC 2004
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 at clubi.ie paul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
Fortune:
It is not enough to have great qualities, we should also have the
management of them.
-- La Rochefoucauld
More information about the NANOG
mailing list