Subject: [mobile-ip] [[email-masked]: Position statement on IKE development]

From: John Wells <[email-masked]>
Date: Fri, 3 Aug 2001 13:10:36 -0400

It's probably a good idea to go forward with a non-IPsec based solution,
particularly in light of this news..

john

-- 
John WELLS
Virginia Tech Networking and Visualization Lab
PGP Public key: http://www.ee.vt.edu/~wells/pgpkey.txt

Subject: Position statement on IKE development
From: "Marcus Leech" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 02 Aug 2001 21:33:47 -0400
List-Id: <ietf-ipsra.vpnc.org>

I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
Schiller, and
  Steve Bellovin, to clarify our position with respect to IKE
development. It is our hope
  that it will clarify, to some extent, some fuzziness in this area that
has evolved over
  the last year or so.

In the several years since the standardization of the IPSEC protocols
(ESP, AH, and ISAKMP/IKE), there have come to light several security
problems with the protocols, most notably the key-agreement protocol,
IKE.  Formal and semi-formal analyses by Meadows, Schneier et al, and
Simpson, have shown that the security problems in IKE stem directly
from its complexity.  It seems only a matter of time before more
analyses show more serious security issues in the protocol design that
stem directly from its complexity.  It seems also, only a matter of
time, before serious *implementation* problems become apparent, again
due to the complex nature of the protocol, and the complex
implementation that must surely follow.

Despite the obviously complex nature of IKE, several proposals have
been put forward to extend ISAKMP/IKE in various ways, for various
purposes.  Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
others do nothing to improve the complexity situation with regard to
IKE as a whole.  While many of these proposals are, individually,
based on sound engineering and reasonably prudent practice, when cast
in the larger context of IKE, it seems clear that they can do nothing
to improve the complexity picture.

It is with that in mind that the Security Area directors in the IETF,
with the consultation of appropriate people on the IESG and IAB, hereby
place a temporary moratorium on the addition of new features to IKE.
It is fairly clear that work on IKE should focus on fixing identified
weaknesses in the protocol, rather than adding features that detract
from the goal of simplicity and correctness.

We are concerned that trying to reuse too much of the IKE
code base in new protocols -- PIC and GDOI come to mind --
will lead to more complex (and hence vulnerable) implementations.
We suggest that implementors resist this temptation, with the
obvious exception of common library functions that perform
functions such as large modular exponentiations.  Attempts
to share state or to optimize message exchanges are likely to
lead to disaster.

The Security Area Directors have asked the IPSEC working group to come
up with a replacement for IKE. This work is underway and is known in
the community as "Son of IKE".  This effort is at serious risk of
suffering the "second system effect", where all the features that were
left out of the first version, end up in the second.  For this to
happen would be a spectacular disaster, and very much detract from the
goal: to produce a more secure, simpler, and more robust version of IKE.

Arriving at this point has been exceedingly difficult and harrowing.
Understandably, egos have been bruised, and the "change not the IKE,
for it is subtle and quick to anger" position has been taken as a
personal afront by some members of the IPSEC community.  Nothing could
be further from the intent of either of the Security Area directors.
If IKE is vulnerable, we must all share a burden of responsibility for
allowing it to get to the state it is in and we must all work together
to correct the problems.

The IPSEC community must act prudently in moving forward with a
replacement for IKE.  The IPSEC auxillary groups (IPSRA, MSEC, IPSP)
must act with good judgment (chairs and members alike) in designing
protocols that don't interfere with the goal of security and
simplifying our IPSEC key-agreement protocol.

Marcus Leech   (IESG)
Jeff Schiller  (IESG)
Steve Bellovin (IAB)

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 4 Aug 2001 09:01:25 +0300

>particularly in light of this news..

It is indeed bad news. But, I'd just like to point out that the position statement
said that a replacement for IKE should be designed (and is being
designed, called Son-of-IKE). That is, a redesign of IPsec AH/ESP
wasn't called for. In the mobile IPv6 case we have already
given up the hope of using IKE to key BUs in the global Internet. 
But we could still use AH/ESP to protect the BUs, BAKE for keying
in the global Internet, and IKE, KINK or Son-of-IKE (when available) for
keying in the Intranet.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 04:31:58 -0700 (PDT)

In fact, it's probably just the opposite: first of
all, it's not really an indictment of IPsec (2401,
2402, 2406) so much as an indictment of IKE. What
that says is that the _last_ thing that MIP should
be doing is positing extensions or new key
distribution protocols when the people who
actually understand this are having serious
trouble getting it right.

		Mike

John Wells writes:
 > Received: from imag.imag.fr (imag.imag.fr [129.88.30.1])
 > 	by birch.ee.vt.edu (8.9.3/8.9.3) with ESMTP id WAA17587
 > 	for <[email-masked]>; Thu, 2 Aug 2001 22:25:59 -0400 (EDT)
 > Received: from horus.imag.fr (horus.imag.fr [129.88.38.2])
 > 	by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pow29664
 > 	for <[email-masked]>; Fri, 3 Aug 2001 04:25:50 +0200 (MEST)
 > Received: from imag.imag.fr (imag.imag.fr [129.88.30.1])
 > 	by horus.imag.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f732PpG20201
 > 	for <[email-masked]>; Fri, 3 Aug 2001 04:25:52 +0200 (MET DST)
 > Received: from above.proper.com (above.proper.com [208.184.76.39])
 > 	by imag.imag.fr (8.11.3/8.11.3) with ESMTP id f732Pkw29647
 > 	for <[email-masked]>; Fri, 3 Aug 2001 04:25:47 +0200 (MEST)
 > Received: from localhost (localhost [[UNIX: localhost]])
 > 	by above.proper.com (8.11.3/8.11.3) id f731gMj04101
 > 	for ietf-ipsra-bks; Thu, 2 Aug 2001 18:42:22 -0700 (PDT)
 > Received: from zcars0m9.ca.nortel.com ([47.129.242.157])
 > 	by above.proper.com (8.11.3/8.11.3) with ESMTP id f731USs03932;
 > 	Thu, 2 Aug 2001 18:30:28 -0700 (PDT)
 > Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
 > 	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f731Tv911913;
 > 	Thu, 2 Aug 2001 21:29:58 -0400 (EDT)
 > Received: from rftzy232.ca.nortel.com by zcars04e.ca.nortel.com;
 >           Thu, 2 Aug 2001 21:30:17 -0400
 > Received: from nortelnetworks.com (acart13a.ca.nortel.com [47.129.8.153]) 
 >           by rftzy232.ca.nortel.com 
 >           with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
 >           id NKPL6BZ0; Thu, 2 Aug 2001 21:29:59 -0400
 > Message-ID: <[email-masked]>
 > Organization: Nortel Networks: Information Systems
 > X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
 > X-Accept-Language: en
 > MIME-Version: 1.0
 > Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3"
 > X-Orig: <[email-masked]>
 > Sender: [email-masked]
 > Precedence: bulk
 > List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
 > List-ID: <ietf-ipsra.vpnc.org>
 > List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
 > 
 > 
 > This is a multi-part message in MIME format.
 > --------------700C1CE7C41A16595853A0C3
 > Content-Type: text/plain; charset=us-ascii
 > Content-Transfer-Encoding: 7bit
 > 
 > --------------700C1CE7C41A16595853A0C3
 > Content-Type: text/plain; charset=us-ascii;
 >  name="statement.txt"
 > Content-Transfer-Encoding: 7bit
 > Content-Disposition: inline;
 >  filename="statement.txt"
 > 
 > --------------700C1CE7C41A16595853A0C3--

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 04:57:52 -0700 (PDT)

I agree with Jari. With the potential exception of
nuking AH (which is discussed and re-discussed
often; Steve Bellovin may make one final attempt
to kill it. I hope.), base 2401 is not what is
really at issue. Indeed, I just spoke to Marcus
about KINK's reuse of IKE phase 2 (quick mode)
and he thought that that was OK as is.

It's main mode (aka the authentication phase)
that needs simplification. This shouldn't be
surprising since it's the Really Hard Problem.

		 Mike