[Ipsec] draft-housley-gigabeam-radio-link-encrypt-00.txt
Tero Kivinen <kivinen@iki.fi> Thu, 04 May 2006 09:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fba9d-0001ue-JA; Thu, 04 May 2006 05:29:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fba9c-0001uW-9F for ipsec@ietf.org; Thu, 04 May 2006 05:29:48 -0400
Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fba9b-0000Lk-Jp for ipsec@ietf.org; Thu, 04 May 2006 05:29:48 -0400
Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k449Tje3027827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 May 2006 12:29:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k449TiIk026379; Thu, 4 May 2006 12:29:44 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <17497.51592.37783.866971@fireball.kivinen.iki.fi>
Date: Thu, 04 May 2006 12:29:44 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Russ Housley <housley@vigilsec.com>
Subject: [Ipsec] draft-housley-gigabeam-radio-link-encrypt-00.txt
In-Reply-To: <7.0.0.16.2.20060503152913.07452050@vigilsec.com>
References: <7.0.0.16.2.20060503152913.07452050@vigilsec.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 13 min
X-Total-Time: 14 min
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: ipsec@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org
Russ Housley writes: > 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. 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... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec
- [Ipsec] draft-housley-gigabeam-radio-link-encrypt… Russ Housley
- [Ipsec] draft-housley-gigabeam-radio-link-encrypt… Tero Kivinen