Subject: [MSEC] Re: Last Call: The Group Domain of Interpretation to Proposed Standard

From: Mark Baugher <[email-masked]>
Date: Tue, 30 Jul 2002 06:53:47 -0700

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
> > [email-masked] or [email-masked] mailing lists by August 12, 2002.
> >
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Brian Weis <[email-masked]>
Date: Tue, 30 Jul 2002 11:21:46 -0700

I'd like to address a couple of common misconceptions about GDOI.

> August 2nd 2001 and partially excerpted here:

GDOI does not actually define a new phase 2 of IKE. It does use IKE
protocol definitions and structures. The GDOI protocol itself however
seeks to separate itself from IKE in the following ways:

* Uses a DOI which is discrete from the IPSEC DOI
* Uses a different port (the draft specifies "MUST NOT run on port 500")
* Specifies no additions to the namespaces or described in RFC 2407 or
changes to the protocols described in RFC 2409

This is a new protocol, not an update to IKE.

Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]