Subject: [Ipsec] draft-housley-gigabeam-radio-link-encrypt-00.txt

From: Russ Housley <[email-masked]>
Date: Wed, 03 May 2006 15:32:29 -0400

http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt

Pleas take a look at this document.  It makes use of IKE to establish 
cryptographic keys to encrypt a point-to-point radio link.  Review of 
the IKE-related portions of this document from members of this mail 
list would be greatly appreciated.

Thanks in advance,
   Russ

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 May 2006 12:29:44 +0300

> list would be greatly appreciated.

As this uses only agressive mode the security considerations should
list the known problems with the aggressive mode (i.e. no DH-group
negotiation, no identity protection, no protection against DoS
attacks) and also general problems in the IKEv1, not mentioned in the
RFC2409 because those were found later (some parts of message not
authenticated (header, version rollback, commit bit, vendor-IDs,
initial contact)).

It should also probably try to specify what to do some problematic
cases in IKEv1, i.e. what to do with life times (what to send, what to
accept), how to handle the case that the delete notifications can (and
will) be lost, thus some kind of black hole detection might be needed,
how to recover from various problems (initial contact), how to do the
rekey properly, i.e. when new keying material is negotiated with the
different KEYSEL bit (i.e. different bit in the SPI), when the other
end can switch to use it (i.e. probably both ends install the inbound
handling before the last message, and the responder starts using it
after seeing message 3 of quick mode, and initiator only after it sees
that responder have started using it). There might also need to be
some text explaining how to do the delete of the previous SA cleanly,
as it might happen that the delete for that is lost and that might
cause the next rekey selects wrong SA (there is only 1 bit selecting
keys there) etc....

I.e. if this protocol is supposed to run over the obsolete IKEv1
protocol, it should also try to explain the problems and probably also
provide some solutions to the problems in it.

Of course the easy fix would be to select to use IKEv2 that already
fixes all those problems...
-- 
[email-masked]