Document Action: 'ECP Groups for IKE and IKEv2' to Informational RFC

The IESG <iesg-secretary@ietf.org> Mon, 22 March 2010 20:55 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 71E433A6978; Mon, 22 Mar 2010 13:55:24 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'ECP Groups for IKE and IKEv2' to Informational RFC
Message-Id: <20100322205524.71E433A6978@core3.amsl.com>
Date: Mon, 22 Mar 2010 13:55:24 -0700 (PDT)
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 20:55:24 -0000

The IESG has approved the following document:

- 'ECP Groups for IKE and IKEv2 '
   <draft-solinas-rfc4753bis-01.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-01.txt

Technical Summary

   This document describes Elliptic Curve Cryptography (ECC) groups
   based on modular arithmetic (rather than binary arithmetic) for use 
   in the Internet Key Exchange (IKE) and Internet Key Exchange
   version 2 (IKEv2) protocols.  These groups were originally described
   in RFC 4753; this document incorporates errata submitted for RFC
   4753 which changes the format of the Diffie-Hellman shared secret
   value.

Working Group Summary

   This document was not the product of any working group.
   No technical issues were raised during IETF Last Call, although
   one reviewer requested notational changes.  These changes
   were not implemented.

Document Quality

   RFC 4753 is referenced as an optional feature in several IPv6
   profiles, and is currrently supported in products for specific
   communities of interest (e.g., US DoD).  These algorithms are
   currently in widespread use by the broader community, but
   are experiencing growth in adoption.

Personnel

   Tim Polk is the Responsible Area Director.  Given the nature of
   this document (essentially incorporation of errata), the AD
   decided to forgo selecting a Document Shepherd.

RFC Editor Note

In the last paragraph of Section 1, please make the following
substitution:

OLD
    These groups were originally proposed in [RFC4753].  This document
    changes the format of the shared key produced by a Diffie-Hellman
    exchange using these groups.  Section 9 provides more details of the
    changes from [RFC4753].  This document obsoletes RFC 4753.

NEW
    These groups were originally proposed in [RFC4753].  This document
    changes the format of the shared key produced by a Diffie-Hellman
    exchange using these groups. The shared key format used in this
    specification appeared earlier as an erratum to RFC 4753, but some
    implementors of RFC 4753 were unaware of the correction and did not 
    implement the errata.  Implementations of 4753 that incorporate the 
    errata are interoperable with implementations of this specification.
    However, there is a potential for interoperability problems between
    implementations of this specification and implementations of 4753
    that did not implement the errata. These problems could be
    difficult to detect and analyze since both use the same code
    point but the secret value (which is probably not available to
    the trouble desk) is computed differently.  Where peers are not
    interoperable, the initiator will never receive a response and
    eventually times out.

    Section 9 provides more details of the changes from [RFC4753].  This
    document obsoletes RFC 4753.