Subject: [IPsec] brainpool summary, suggested way ahead, and comments on draft

From: Sean Turner <[email-masked]>
Date: Fri, 21 Sep 2012 10:19:48 -0400

I'd like to discuss the IEEE's request for brainpool code points 
additions in the Group Description registry 
(https://www.iana.org/assignments/ipsec-registry) on this mailing list. 
  I realize it's not in scope of the WG, but all the right people are 
here so I'd like to ask for the wg chair's and member's indulgence on 
this matter.

Here's the summary of events as I remember them:

Stephen and I got an informal liaison from IEEE 802.11 requesting code 
point assignments in the Group Description section of 
https://www.iana.org/assignments/ipsec-registry.  Since then we've 
received the official liaison.  And we figured inviting Dorthy along to 
secir would cut down on some email.

My initial thought was that adding anything to this registry was an 
update to IKEv1 and that was pretty much a no-go because IKEv1 is 
obsolete.  But, the registry is RFC required so that's not strictly 
true.  That is, other code points have been assigned after IKEv1 was 
obsoleted.

The other thing that came to light was that the code points were in fact 
not going to be used by IKEv1 they were being used by another protocol, 
the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol.

I think it's fair to say that at the meeting most people weren't 
thrilled that IEEE plans to reuse the registry.  We discussed setting up 
a new registry or pointing from the existing registry to a new registry, 
but the IEEE folks didn't like that because their spec is apparently not 
up for change until 2015 (Tero has submitted comments on this topic in 
IEEE).

What I thought we came to was that Dan would publish a draft that 
requested the points and that the "notes" column would contain "not for 
IKEv1" - and then we'd talk about it.  Dan submitted the draft 
requesting 14 code points with "not for IKEv1" in the notes column for 
each code point.  I forwarded it to secdir and here we are.

^
| summary

| way ahead discussion
v

 From the discussion following publication, it's still clear the dual 
use of the registry is still unloved.  I share that view.  I think it 
comes down to this:

- On the one hand, putting "not for IKEv1" in the notes column assumes 
that whoever consults the registry will make note of the note and not 
implement (or ask for them to be implemented) the code points in IKEv1. 
  Concerns have been expressed that the note won't be enough to stop 
people asking for IKEv1 products to support these new code points - not 
thrilled about this prospect.

- On the other hand, getting the IEEE spec to point to a new registry is 
(or might be) a no-go because of their publishing cycle.  Assuming the 
IEEE spec can't be changed and we don't assign the code points, I'm sure 
some kind of inter-SDO struggle/spat will occur - not thrilled about 
this this prospect either.

In this unfortunate situation, I'd like everyone to consider the (third 
surgically attached) hand that shares the burden: reserve the code 
points for 802.11 SAE in the Group Description registry, be very 
explicit about it in the draft/regstry, and then point from the Group 
Description registry to another registry (thanks to whoever suggested 
this at the secdir lunch we probably should have explored this more). 
The burden is then shared by the IETF assigning code points for 
something some despise/dislike and the IEEE implementers following an 
additional link from the registry they've already got to consult  (they 
have to follow the link because the registry values aren't copied to 
their spec).  The registry entries would appear as follows (well Value, 
Group, Reference, and Notes would normally appear on one line but it 
wraps in email and I thought this would be easier to follow):

Value
-----
27-y

Group
-----------------------
Reserved for 802.11 SAE

Description
------------------
This specification

Notes
-----------------------------------------
Not for use with IKEv1 - see xyz registry

and then link 27-y to the curve names in the xyz registry (more on the 
number of code points at the end):

Value Group                          Reference
----- ------------------------------ ------------------
27    X-bit Brainpool: brainpoolPXr1 This specification
...   ...                            ....

Thoughts about this?

| comments on draft
v

I'd like to make to the draft clearer about what's going on:

#1) Retitle:

OLD:

  Brainpool Elliptic Curves for the IKE Group Description Registry

NEW:

  Brainpool Elliptic Curves for 802.11 SAE in the
          IKE Group Description Registry

#2) tweak abstract:

OLD:

  This memo allocates code points for fourteen new
  elliptic curve domain parameter sets over finite
  prime fields into a registry established by The
  Internet Key Exchange (IKE).

NEW (where X is TBD at this point):

  This memo allocates code points for X new elliptic
  curve domain parameter sets over finite prime fields
  into a registry established by The Internet Key
  Exchange (IKE).  These values are used by the IEEE
  802.11 SAE (Simultaneous Authentication
  of Equals) protocol.  The values found in this
  document are not for use in IKEv1.

#3) tweak intro:

OLD:

  IANA maintains a registry for [RFC2409] to map
  complete domain parameter sets to numbers.  Other
  protocols, for example [IEEE802.11], refer to this
  registry for its convenience.  Therefore, this memo
  instructs IANA to allocate new code points for the
  Brainpool curves defined in [RFC5639] to the registry
  established by [RFC2409].

NEW:

  [RFC2409] defined the Group Description registry that
  other protocols, for example [IEEE802.11], refer to for
  convenience. Non-IKE protocols referring to the registry
  is not ideal but also not a problem until the non-IKE
  protocol(s) want values added to the registry and these
  values are not for use by IKE.  This is the case with the
  values in this document; they are not for use with IKEv1.
  The values in this document are for the Brainpool curves
  defined in [RFC5639] use with 802.11 SAE and the
  documents only purpose is to instruct IANA to allocate
  new code points.

#4) Pick fewer curves.  Not sure which ones but if we end up doing 
brainpool in TLS I'd like to see us pick the same ones.  Not sure which 
ones those will be.  I'm thinking like 3 - probably lining up with the 3 
ECP groups.

#5) Once we've settled on the format for the registry put it exactly as 
agreed in the IANA section.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Sep 2012 11:19:00 -0700

This all works for me, adding #6) Remove the snark.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 21 Sep 2012 22:39:40 +0300

Same here. Thanks Sean!

	Yaron

On 21/09/12 21:19, Paul Hoffman wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 21 Sep 2012 14:42:59 -0700 (PDT)

Hi Sean,

  There's some missing (pre)history and context. Let me try to fill it in.

  Back in early July, Johannes Merkle sent a note to the list saying he
wanted to use the elliptic curves proposed by the ECC Brainpool with
IKE and IPsec. He asked a series of questions, one of which was:

  "Should we include IKEv1 in the specs as well?"

I voiced support but there was some opposition along the lines of:

  * we cannot update the IANA registry of an obsoleted protocol.
  * it is not appropriate for a protocol other than RFC 2409 to use
     the IANA registry created by RFC 2409.

Both of these are wrong. RFC 5114 updated this very same registry
after RFC 2409 was obsoleted and there was no hullabaloo over
that action. And RFC 5931 (EAP-pwd) uses that registry and it
got approved for publication long after RFC 2409 was obsoleted,
again without any hullabaloo.

  There is no valid process reason to not just let Johannes's draft
update the IKEv1 registry while it's updating the IKEv2 registry
(just like RFC 5114 did) and there is precedence which we could
just follow to avoid all this mess.

  In spite of that. it was decided to not update the IKEv1 registry
with the Brainpool curves. When IEEE got wind of this, they sent
a request, via the IEEE-to-IETF liaison, to please reconsider since
they have more than 1 protocol used in 802.11 that reference
that registry (i.e. it's not just SAE). The concern was that there
may be administrative or regulatory reasons for some entity to
desire or require using the Brainpool curves and 802.11 wants
to ensure that it can be used everywhere, or at least not
prohibited from being used because of a misguided effort by
the IETF to kill off use of a different protocol.

  It is the nature of this reconsideration-- forbid IKEv1 from using
the updated registry or create some new registry and forbid IKEv1
from using it-- that is causing this whole kerfuffle. IEEE 802.11's
long (from our standpoint) revision schedule is not the cause of
the problem here.

  The reason to not just update the IKEv1 registry with the Brainpool
curves and to prohibit it's use with these curves is, apparently,
the concern that someone somewhere might actually use them with
IKEv1. It is not a certainty that that will happen and, furthermore, it
is not apparent to me what calamity will befall us all if somebody did.

  So my preference would be to follow existing precedence and let
Johannes's draft update both registries without any ridiculous notes.
If that were to happen we could let my draft die a natural death and
end the kerfuffle. If that just cannot be then I'll update my draft to
reflect your proposed edits, with the modification that this is not just
for SAE and not just for 802.11. Also, if you want to limit the number
of curves (item #4) you should coordinate with Johannes on his draft
for the IKEv2 registry as well as his TLS draft.

  regards,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Sep 2012 14:02:53 +0300

Dan Harkins writes:
> that action.

When draft-lepinski-dh-groups was discussed in the ipsec-list we were
most concerned about the format of the KE payloads and so on, and I do
not think anybody actually even reacted to the fact that it updates
IKEv1 registry too. At that point it was also 2 years since the IKEv1
was obsoleted, now it is 7 years, so I do think there is a difference.

> And RFC 5931 (EAP-pwd) uses that registry and it

Never knew that RFC 5931 is using that same registry. This was not
pointed out in the IPsec list, thus I think most peoples just didn't
realize the issue. The fact that it uses the registry of the obsoleted
IKEv1 protocol, is said like this in the RFC:

   The Group Description field value is taken from the IANA registry for
   "Group Description" created by IKE [RFC2409].

There is no link to the registry itself, no IANA considerations
section comment, only saying the group description field is taken from
that registry.

I think one of the problems we have in IANA registries is that, we do
not have back pointers. I.e. it is impossible to know which protocols
use which registries. If the protocol just uses (instead of making
additions to it) the IANA registry, there is no need for IANA actions,
thus IANA (or the expert or WG etc) is not even aware of the fact that
some protocol is using some registry.

Perhaps we should start adding some kind of back pointers to the IANA
registries, i.e. which protocols use which registry. 

> just follow to avoid all this mess.

It is time to stop updating obsoleted IKEv1 protocol. Even when there
has been case where it was approved 5 years ago, that does not mean we
are going to do it forever.

> that registry (i.e. it's not just SAE).

I could not find any other protocol than SAE, can you give me
references to which other IEEE protocols use that registry directly
(i.e. not through some RFC).

> The concern was that there may be administrative or regulatory
> reasons for some entity to desire or require using the Brainpool
> curves and 802.11 wants to ensure that it can be used everywhere, or
> at least not prohibited from being used because of a misguided
> effort by the IETF to kill off use of a different protocol.

Which is exacty the reason why protocols should not reuse registries
from other protocols. If IETF wants to kill of some protocol, it
should be able to do so. And if IETF wants to say that there is no
more additions to that protocol, that should be possible, even when
some other STD (or RFC) uses that protocol.

> long (from our standpoint) revision schedule is not the cause of

I do not think IEEE revision schedule is that long. Our drafts to RFCs
cycles are around 2-4 years in normal case (and close to 10 years for
slow documents) I do not think IEEEs revision cycle is that long.

I think there is also errata for IEEE documents, but I do not know how
that works. There is also some kind of faster and more lightway way of
making some fixes/additions to documents, at least that was told to me
in the 802.15.9 session when we were talking about that we need some
changes to some other documents.

For example I think updating the pointer from IKEv1 registry to its
own registry for this IEEE document is something that could be done on
errata. Checking at the errata documents for other IEEE documents
(http://standards.ieee.org/findstds/errata/index.html) they do seem to
change things like "32 s" -> "32 µs", which is quite big technical
change (http://standards.ieee.org/findstds/errata/802.11h-2003.pdf),
compared to this pointer change.

Especially if the IKEv1 registry is made so that it points to the new
registry, so regardless whether IEEE users notice the errata or not,
they finally get to the right place.

> for SAE and not just for 802.11.

You should actually enumerate for which protocols it is then. If there
is even more than 802.11 SAE and RFC 5931, then it will affect the
discussion here.

For example the RFC5931 can be Updated by your new draft and RFC 5931
should now use the newly created registry for groups, and we can add
another note to the old IKEv1 registry pointing RFC 5931 users to this
new registry. 

> Also, if you want to limit the number of curves (item #4) you should
> coordinate with Johannes on his draft for the IKEv2 registry as well
> as his TLS draft.

Yes.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Sep 2012 15:55:54 +0300

> use of the registry is still unloved.  I share that view.  I think it 

Actually as Dan pointed out it is not only dual use, as there is other
protocols using the registry. I think this makes it even more clear
that we want them to refer to another registry, not reuse the IKEv1
registry. 

> thrilled about this prospect.

And next questions comes to implementors reading the registry: "This
is IKEv1 registry, and these entries are 'not for IKEv1', so for what
reason they are added here?"

Which means we still need to add pointer to other protocols /
specifications using the registry. 

> this this prospect either.

Actually we should propably make formal request to ask from IEEE what
other options there are, i.e. I know they have errata, they also make
amendments which are then rolled in to the their actual standards, and
most implementors actually already implement those amendments as soon
as they are ready. I also think they have some kind of maintenance
process which is allowed to make changes (additions etc) to the
standards without going through the full amendment process for simple
things (for example allocating just one number).

I think all this also depends on the working group (i.e. 802.11 here),
so it would need to get some 802.11 WG officials to answer whats their
processing rules for all those.

Unfortunately I was not able to be in the last IEEE interm meeting,
and I am going to miss next plenary too, so I cannot ask those
questions from the people who know more in person. 

> wraps in email and I thought this would be easier to follow):

I think that would be good way forward. Also it might be possible to
make errata for their specification to point to the right registry
directly. There is also the RFC 5931 which reuses same registry. Is
there other RFCs? 

> ones those will be.  I'm thinking like 3 - probably lining up with the 3 

Actually if the new registry is going to be Generic Group Description
registry, I see no reason to limit the number of groups that it can
include. It will most likely be 16-bit registry or similar, thus there
is enough space for everything.

On the IKEv2 and TLS we can limit the number of groups if we like, but
I see no reason why this generic "group description" <-> "group
number" registry should be limited to only certain groups. Actually it
could be something like "first come first served"-allocation policy
and anybody could allocate any group from there just to get number it
can use in other protocols.

If this is going to be registry only for IEEE 802.11 SAE, then we most
likely need to ask from them what do they want to have for allocation
policy. 
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 25 Sep 2012 10:59:47 -0700 (PDT)

> was obsoleted, now it is 7 years, so I do think there is a difference.

  There is no time limit that I'm aware of that suddenly makes an
acceptable process suddenly become unacceptable.

> realize the issue.

  I brought it up at the SAAG meeting back in Vancouver. You were
there.

> are going to do it forever.

  I will admit that you are repeatedly making that assertion but it's just
some sort of argumentum ad infinitum/absurdum statement. There is
no reasoning behind your assertion. Just "we must stop!" and "we
cannot continue forever!"

  You essentially admit that there is no process reason to not just
update the registry and there's really no prohibition on other protocols
referring to the registry that was created by another protocol. You
may not like it, but that is not a legitimate reason.

  You snipped out the portion of my email where I noted that I did
not foresee any calamity that would befall us all if the IKEv1 registry
is merely updated in the same way it was by RFC 5114-- just add the
code points without any back pointers or front pointers or ridiculous
notes. So let me ask you directly:

    What calamity will befall us all if the IKEv1 registry is just updated
    in exactly the same way that RFC 5114 updated the registry?

> (i.e. not through some RFC).

  There is a novel use of an unauthenticated Diffie-Hellman by
the audio/visual streaming protocol (added by TGaa).

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Sep 2012 16:46:44 +0300

> acceptable process suddenly become unacceptable.

There is no time limit that suddenly causes that, but the longer the
protocol has been obsoleted, the more questionable there is to make
additions to it. I do think there is difference whether the addition
is proposed 1 day after the new version is out or whether it is done
20 years later. What the exact number of years will be is of course
personal opionion, and at least for me it should be less than 7
years, meaning we are already past it...

It seems you disagree on me on that, so it is better just agree that
we disagree on this issue.

>   I brought it up at the SAAG meeting back in Vancouver. You were

Saag meeting? I assume you mean secdir lunch. I did miss some of the
discussion in the secdir lunch as sometimes it is hard to hear people
there (no microphones, people talking over each other), and especially
RFC numbers do tend to go past me, as I people do say them very
quickly, and I need to parse them before I can know which number it is
and even after that I usually do not have any idea what protocol that
is.

Meaning: I did miss that statement there even when I was there. That
happens. This means it is good that you pointed it up here too.

> cannot continue forever!"

We did obsolete the IKEv1 protocol. So I assume that was supposed to
mean something. If we continue to make additions to it, why did we
obsolete it? I think there is good thing to have some kind of grace
period after the protocol is obsoleted, and replaced with new, during
which there is still some work that can be done (or most likely
finished) for the old protocol, before we move all work to new
protocol.

You seem to feel that the fact that the protocol is obsoleted does not
mean anything, and that we should continue work for that forever. You
ar just making that sort of arguments over and over again, without
providing any reasoning behind that.

If you want reasons I can give you some: IKEv1 is BAD protocol. IKEv2
is much better protocol. IKEv2 include standardized ways of doing lots
of things that are done in undocumented (incompatible) vendor specific
extensions in the IKEv1. IKEv1 do have known security vulnerabilities
especially for those vendor specific extensions, as vendor ID payloads
and notifications are not authenticated at all during the initial
main mode / aggressive mode exchange. IKEv1 vendor specific
configuration payload and xauth exchanges do have known security
vulnerailities by using group shared keys (there are some vendor
specific extensions which do not have those problems (hybrid-mode)).

Then there is lots of smaller things in the implementations, for
example retransmission logic, dead peer detection, crash recovery etc.

I do think there was good reasons why IKEv1 was obsoleted.

I do know that some of those could have been fixed quite easily by
making additions to IKEv1, but that was not allowed because of the
IETF policy reasons, thus we had fix it by making the IKEv2 and fix
all known issues there. 

> may not like it, but that is not a legitimate reason.

As far as I know there is no reason for random protocol Y using
registry from protocol X. That does not mean that protocol Y has any
saying whether anything is added to the registry X. Depending on the
IANA allocation policies different parties decide whether that is
allowed or not. In this case it is up to the IESG to decide as the
registry is RFC required. At least this is my understanding of the
issue, but I am not IETF policy person, so I might be wrong...

Security area director asked us on this mailing list to comment about
the issue, so thats why I am commenting.

I personally do think it would be much better to create separate
registry for these other generic group description to identifier
mappings for these other protocols, and leave them out from IPsec
registry. That would fix the problem, that we do not need to modify
IKEv1 registry, and those other protocols can add their numbers to the
registries at will.

What do you have against that solution?

>     in exactly the same way that RFC 5114 updated the registry?

I see some of our customers asking when are we going to implement them
for IKEv1. We do IPsec toolkit. Some of our customers go through RFCs
and IANA registries and make tick marks for every single option there
is, and want to have support for it, regardless whether it makes sense
or not.

In first I would most likely be able to say that those numbers are not
meant to be used for IKEv1, but if there is no note or so in the
registry, they would ask why not? Later if some of the other vendors
after similar perssurce happens to implement them, then our customers
would be more and more asking why we do not implement them. As it just
going to be tick mark in their sheets they do not care that we already
implement them in IKEv2 and that would mean we would have again added
new feature to already obsoleted protocol, which should have died
several years ago. 

> the audio/visual streaming protocol (added by TGaa).

Good to know, need to check that one too. 
-- 
[email-masked]