Re: Last Call: The Group Domain of Interpretation to Proposed Standard

Mark Baugher <mbaugher@cisco.com> Tue, 30 July 2002 14:53 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UErTw27213; Tue, 30 Jul 2002 07:53:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22075 Tue, 30 Jul 2002 09:42:44 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020730065043.04afccb8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Jul 2002 06:53:47 -0700
To: Dan Harkins <dharkins@tibernian.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard
Cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com
In-Reply-To: <200207300143.g6U1hKwV022982@mail2.trpz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Dan
   GDOI is not subject to ipsec moritoriums since it is a product of 
msec.  You cite Steve Bellovin and Jeff Schiller.  Steve is reviewing GDOI 
for us.

Mark
At 06:42 PM 7/29/2002 -0700, Dan Harkins wrote:
>   This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2"
>exchange to be protected by an IKE Security Association established
>in a "phase 1" exchange. There is currently a moratorium on doing this
>as was explained by Marcus Leech (then co-AD) on behalf of himself,
>Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on
>August 2nd 2001 and partially excerpted here:
>
>   "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."
>
>   GDOI does indeed share state from IKE. It requires the authenticated and
>secret keys IKE derives, among other things (like "cookies", etc). It was
>even explicitly mentioned in the Position Statement as a source of
>concern.
>
>   I urge the IESG to reject the request to advance this draft to Proposed
>Standard as it will lead to more complex and vulnerable implementations
>and "likely lead to disaster."
>
>   Dan.
>
>On Mon, 29 Jul 2002 14:22:28 PDT you wrote
> >
> > The IESG has received a request from the Multicast Security Working Group
> > to consider The Group Domain of Interpretation
> > <draft-ietf-msec-gdoi-05.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 2002.
> >
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt