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

[Brian Weis <bew@cisco.com>]

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

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:

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

>   "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

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com