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