Resolution of IKEV2 Open Issues

[tytso@mit.edu]

A week ago, Barbara and I sent out a list of the open issues remaining
with IKEv2 after the San Francisco IETF meeting.  After looking at the
discussion on the mailing list, this is how we believe these issues were
resolved:

A.  Issues settled at San Francisco to be confirmed on the mailing list.

  1.  Use of a la carte negotiation.     No discussion, CONFIRMED

  2.  Not killing Me Tarzan, You Jane.    No discussion, CONFIRMED

  3.  Identity handling.   Discussion on the list produced the following
      wording (suggested by Paul Hoffmann) to replace the first
      paragraph of seciton 3.5 of ikev2-06 with:

        The Identification Payload, denoted ID in this memo, allows
	peers to assert an identify to one another. This identity may be
	used for policy lookup, but does not necessarily have to match
	anything in the CERT payload; both fields may be used by an
	implementation to perform access control decisions.

B.  DHCP over IKE versus CP.

    Tero submitted I-D's for consideration, and we invited comment on
    Tero's proposal as a substitute for Configuration payload.  In the
    discussion which followed, a number of people on the list asserted
    that they believed that either would work.  Darren Dukes provided a
    good summary of the tradeoffs in his message of April 10, 2003, for
    which there was little dispute.  The only thing which does seem to
    be in dispute is how to weigh the advantages and disadvantages of
    the two solutions.

    Although this is not a vote, it is instructive to look at the
    positions of the people who contributed to the discussion:

    Flip a coin: Derek Atkins, Scott Kelley

    DHCP/IKE: Michael Richardson, Bill Summerfeld (don't re-invent DHCP,
        easier reuse of non-IPSEC network infrastructure), Francis Dupont
	(doesn't believe CP is proper solution for IPv6), Michael Thomas,
	Tero Kivinen

    CP: Darren Dukes (slight preference. flip a coin, but prefer CP
        because it's in the spec), Ravi Kumar, Charlie Kaufman (because
        it's simpler), Jim Knowles, Jing Xian (simplicity and
        performance), Andrew Krywaniuk (worried about danger of blindly
        forwawrding an unauthenticated packet to DHCP server into the
        intranet) 

    At the San Francisco IETF, the decision criteria which we set was
    that Configuration Payload was the default answer, and in order to
    replace CP with an alternate proposal, strong support was needed.
    This was a tough call, but ultimately, Barbara and I have to
    conclude that this bar was not met.  Although many well-respected wg
    participants argued in favor of DHCP over IKE, many other wg
    participants were in favor of keeping the existing Configuration
    Payload.

    It should be noted that this does not permanently preclude use of
    DHCP as a configuration mechanism for IKE; this decision only
    affects what will be in the IKEv2 specification.   For those people
    who continue to believe that DHCP is needed for their application,
    they are invited to approach the Security AD's and pursuade them
    that there is a sufficient constituency for this work to persue
    standardization in of a DHCP-style solution (either using a RFC
    3456-style approach, or a DHCP over IKE approach) as a stand-alone
    document.  This work could either take place in a new working group,
    or be assigned to the IPSRA working group.

C.  Issues that have arisen on the mailing list since San Francisco

1.  Protection of initiator's identity against active attacks for EAP
    case.  As we stated earlier, this issue was raised previous to the
    San Francisco meeting, and did not then receive sufficient support.
    We believe the changes necessary to provide this functionality are
    sufficiently invasive and sufficient complexity (by essentially
    making legacy authentication an entirely new protocol with payloads
    appearing in different order and with different levels of
    protection) that we believe that we can not pursue functionality at
    this late date.

2.  Tero's proposal for a new source-address changed notification
    payload.  While soluable, some issues were raised about how to best
    accomplish this functionality.  So we believe this work should be
    deferred to separate, stand-alone specification.

3.  Uri's AES PRF proposal.  Not at this time; waiting for more
    intensive cryptographic review by the Cryptography Research Working
    Group. 

4.  Michael Richardson's proposal to define separate payload numbers for
    IDi and IDr.  Let's just do it.

5.  Lack of definition of COOKIE_REQUIRED payload.  Use Charlie's
    suggestion to delete COOKIE_REQUIRED and to simply use the COOKIE
    payload.

6.  Remove language about required cryptographic algorithms.  This
    question of which algorithms are mandatory to implement is to be
    deferred to another specification, which Jeff Schiller is authoring.

7.  Peer address protection and NAT traversal issues.  The issues which
    Francis Dupont has been raising, have for the most part, failed to
    achieve resonance with the working group.  In particular, there
    seems to be no conensus that the "pseudo-NAT attack" is one which
    should raise concern, and there seems to be no consensus that the
    NAT traversal functionality should be capable of being
    administratively prohibited.  That being said, we would like Charlie
    to examine Francis's e-mail message of April 10, 2003, with the
    subject "IKEv2 draft 6 (details)", as there were a few spelling
    errors and other clarifications which do seem appropriate.


NEXT STEPS
==========

With these issues addressed, Barbara and I believe that the next step is
to ask Charlie to make these final edits to ikev6 I-D.  Once the -07
draft is published by the secretariat, we will initiate a working group
last call.   This will be a final opportunity for people to make
comments on the draft.  However, during working group last call, the bar
required for the working group to take action will be higher than during
this previous phase of discussion.

Once the working group last call is finished, and any necessary comments
are addressed, we will forward the IKEv2 specification to the IESG, and
the entire ipsec working group can give itself a well-deserved pat on
the back for achieving this milestone.

						Ted and Barbara