[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec mailing list
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
I don't see any reason that Change_Message's (6.1) cannot be replayed,
and this could could be used as a denial of service mechanism. The
Change_Message's have mutated significantly since Hugo's original
comments, but I think his observation that there is no replay
prevention is valid.
There's enough support in the protocol for replay detection if some
restrictions are made on SPI reuse. Some sort of timestamp or sequence
number would reduce the amount of storage needed to provide replay
protection, but it's not really necessary.
I think the "change" message is misnamed, since it either creates a
new SPI, or deletes an existing one. I'm not going to suggest edits
to change that, however....
The draft doesn't explicitly disallow modifying an existing SPI, but
it doesn't specifically allow it, either. I don't see how one could
change arbitrary SPI attributes reliably, since packets sent using the
SPI could be reordered around the change request.
The fix is relatively simple:
- limit the lifetime of the shared secret, and require that
photuris remember the existance of all SPI's created using the shared
secret until the shared secret expires.
- --
Here's my suggested additions to the spec; there's admittedly some redundancy
here, but I don't think it's excessive.
[these should go into section 5.4]:
The shared secret, and any SPIs created using it, must be
destroyed once the initial SPI, created here, expires.
[These should go into section 6.4 implementation guidelines]:
Change_Message packets must not be allowed to *modify* already
existing SPI's, or to resurrect SPI's which have been deleted.
If an otherwise-valid change_message is received which would produce
an SPI which would live beyond the expiration time of the shared
secret, the new SPI must be silently adjusted to expire when the
shared secret expires.
To prevent resurrection of already-used SPI's, implementations MUST
remember, but mark as unusable, deleted or expired SPIs until the
shared secret used to create them also expires.
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBMHmMqlpj/0M1dMJ/AQEkHQP9Gt+9c4046ACcvzZxfP0m39S25B5zDVhE
ukp3WqRC7RlHCkHo4tf9IR7aL5UXR+y2K/oecpVH0tyQ3G+EywIn630LvvOqU3l6
YelJzN8hueDS0dJ3Gd4ZgrQ4JJlNkLUEGtEL4mJzd4n44PxMT6l8IHYlzzpUER0K
QD7lFVAFrDM=
=dMo5
-----END PGP SIGNATURE-----
References: