Skip to main content

Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
draft-harkins-brainpool-ike-groups-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Brainpool Elliptic Curves for the IKE Group Description Registry' to Informational RFC (draft-harkins-brainpool-ike-groups-04.txt)

The IESG has approved the following document:
- 'Brainpool Elliptic Curves for the IKE Group Description Registry'
  (draft-harkins-brainpool-ike-groups-04.txt) as 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 Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/


Ballot Text

Technical Summary

The draft allocates code points for four new elliptic curve domain
parameter sets (ECC Brainpool curves from RFC 5639)
over finite prime fields into a registry that was established by the IKEv1
(https://www.iana.org/assignments/ipsec-registry) but is used by other
protocols (IEEE 802.11aa, IEEE 802.11s, RFC 5931). 

Working Group Summary

The draft was discussed quite controversially on the WG mailing list.
There are persons in the WG that strongly feel
that no further code points should be defined for IKEv1 because the
protocol has been deprecated long ago (by RFC 4306).
Other persons in the WG argued that IKEv1 is still widely used in
practice and, furthermore, other code points have been
assigned previously to the same name space after IKEv1 was obsoleted. No
consensus could be achieved on this topic. On
the other hand, the ADs received an informal liaison statement from IEEE
802.11
(https://datatracker.ietf.org/liaison/1181/) requesting code point
assignments for these curves in the IKEv1 registry.
IEEE standards 802.11aa and 802.11s are using this name space of the
IKEv1 registry, and these specs are apparently not
up for change until 2015. The matter was discussed at the SAAG meeting
among the ADs and the WG members present and it
was decided to publish an internet-draft that requests these code points
but also requires IANA to add a note that they
are not for IKEv1. In the WG discussion following its publication,
concerns were uttered that the note won't be enough
to stop people asking for IKEv1 products to support these new code
points and to prevent implementers to use them for
IKEv1. On the other hand, it was expressed that requiring the IEEE specs
to point to another (new) registry is probably
not possible due to their publishing cycle. Alternative solutions were
discussed, e.g. to include in the registry only a
link pointing to another registry where the actual values are listed.
Eventually, the approach of the draft, i.e. to
include a note "not for IKE" in the registry, was widely considered the
best way forward.

After some comments on earlier versions, an announcement of a revised
draft on the ipsecme mailing list did not result
in any further comments.

There was agreement that the draft shall not be a WG document. 

Document Quality

Some specific comments of Tim Polk were accommodated in a revision. 

Personnel

The Document Shepherd is Johannes Merkle, the sponsoring AD is Sean Turner. 

RFC Editor Note