[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: