[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