Subject: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry

From: "Pearl Liang via RT" <[email-masked]>
Date: Wed, 8 Feb 2012 02:07:59 +0000

Hi, Tero,

This is very useful information.  I've revised the ipsec-registry to 
include your edits (included below).  Though I have a few remaining 
questions:

- For Registry Name: IPSEC Authentication Methods (Value 3)
> Registry Name: IPSEC Authentication Methods (Value 3)
> Current: Standards-track RFC
> 
> There is nothing about this in the RFC2409, so I would say either "RFC
> required" or "Specification required" would be ok. There is draft
> http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already
> proposing this change.

Question1: since a new document is in work to update this, 
the registration procedures will be updated when the document is made 
to IETF Last call.  Would it be okay to not change the listed 
registration procedures at this time?  

- For Registry Name: PRF (Value 13)
> Registry Name: PRF (Value 13)
> Current: Standards-track or Informational RFC
> 
> There is nothing about this in the RFC2409, so I would say either "RFC
> required" or "Specification required" would be ok. 
>

Question2: Would it be sufficient to list "RFC required" only?

- For these 'early assignment' registrations as per ietf-ipsec-ike-ecc-groups,
you commented the following:

> > 6 EC2NGF163Random2
> > 7 EC2NGF163Koblitz
> > 8 EC2NGF283Random
> > 9 EC2NGF283Koblitz
> > 10 EC2NGF409Random
> > 11 EC2NGF409Koblitz
> > 12 EC2NGF571Random
> > 13 EC2NGF571Koblitz
> 
> These are from the
> http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version,
> i.e. the registry was updated at some point in 2002 even when the
> registry had registration policy of "RFC Required" and the document
> was still draft (and was never published as RFC).
> 
> I think you should remove "Panjwani" and "Blake-Wilson" and put
> "ipsec-ike-ecc-groups" for all of them, and put some down a footnote
> saying that the registry was updated too early and the draft never
> made it to the RFC, but as these values might be used by some
> implementations they are left there in the registry, but new
> implementations should not use them. Also the reference could point
> out that the values in the registry match the -04 version of the
> document.

[pl] I have removed the version number from the draft string.  (I was
unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.)
I have also remove both "Panjwani" and "Blake-Wilson" from the registry.
I have also marked the draft-ipsec-ike-ecc-group as expired in 
the registry since it has never made it to an RFC.
Regarding the footnote, I've drafted something as follows:

[[
Note: these values were reserved as per draft-ipsec-ike-ecc-groups which 
never made it to the RFC.  These values might be used by some 
implementations as currently registered in the registry, but new 
implementations should not use them.
]]

Question: does the above look okay?  Please comment.  When I receive 
your edits, I will add the "Note" to the registry.

Please see: http://www.iana.org/assignments/ipsec-registry

When you have updates for the isakmp-registry, please send them
to us.

Thank you again for your help,
~pearl

On Mon Jan 09 08:24:39 2012, [email-masked] wrote:
> [I CCed the [email-masked] list, as this changes the registration
> policies, and we have already had some discussion about this earlier
> on the list and other people there might also have their opinion about
> the matter.]
> 
> Pearl Liang via RT writes:
> > 1) What are the registration procedures for these sub-registries 
> > listed in http://www.iana.org/assignments/ipsec-registry:
> > 
> > - Exchange Type
> > - Additional Exchanges Defined-- XCHG values
> > - Next Payload Types
> > - Notify Message Types 
> >   - Notify Messages - Error Types (1-8191)
> >   - Notify Messages - Status Types (16384-24575)
> > 
> > ?  I would like to update "Not defined" if possible.
> 
> For most of those it is not defined... I.e the original RFC does not
> specify any registration procedures for them (or for some other
> registries we have there).
> 
> I would most likely think it would be best to put them as
> "Specification required" or "RFC required".
> 
> Actually I think we should go through the RFC2407-2409 and see from
> there for which registries they do specify any registration policies,
> and use those values for only those registries and put everything else
> as "Specification required" or "RFC Required".
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Attribute Classes
> Current: Standards-track RFC
> RFC2409: 11.1 Attribute Classes
> 
>    Attributes negotiated in this protocol are identified by their class.
>    Requests for assignment of new classes must be accompanied by a
>    standards-track RFC which describes the use of this attribute.
> 
> -> Standards-track RFC, already OK
> 
> ----------------------------------------------------------------------
> 
> Registry Name:  Encryption Algorithm Class Values (Value 1)
> Current: Standards-track or Informational RFC
> RFC2409: 11.2 Encryption Algorithm Class
> 
>    Values of the Encryption Algorithm Class define an encryption
>    algorithm to use when called for in this document. Requests for
>    assignment of new encryption algorithm values must be accompanied by
>    a reference to a standards-track or Informational RFC or a reference
>    to published cryptographic literature which describes this algorithm.
> 
> -> Specification required, currently this is Standards-track or
>    Informational RFC, but I think Specification required is closer to
>    what the RFC says about "a reference to published cryptographic
>    literature". 
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Hash Algorithm (Value 2)
> Current: Standards-track or Informational RFC
> RFC2409: 11.3 Hash Algorithm
> 
>    Values of the Hash Algorithm Class define a hash algorithm to use
>    when called for in this document. Requests for assignment of new hash
>    algorithm values must be accompanied by a reference to a standards-
>    track or Informational RFC or a reference to published cryptographic
>    literature which describes this algorithm. Due to the key derivation
>    and key expansion uses of HMAC forms of hash algorithms in IKE,
>    requests for assignment of new hash algorithm values must take into
>    account the cryptographic properties-- e.g it's resistance to
>    collision-- of the hash algorithm itself.
> 
> -> Specification required, see above.
> 
> ----------------------------------------------------------------------
> 
> Registry Name: IPSEC Authentication Methods (Value 3)
> Current: Standards-track RFC
> 
> There is nothing about this in the RFC2409, so I would say either "RFC
> required" or "Specification required" would be ok. There is draft
> http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already
> proposing this change. 
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Group Description (Value 4)
> Current: Standards-track or Informational RFC
> Registry Name: Group Type (Value 5)
> Current: Standards-track or Informational RFC
> RFC2409: 11.4 Group Description and Group Type
> 
>    Values of the Group Description Class identify a group to use in a
>    Diffie-Hellman exchange. Values of the Group Type Class define the
>    type of group. Requests for assignment of new groups must be
>    accompanied by a reference to a standards-track or Informational RFC
>    which describes this group. Requests for assignment of new group
>    types must be accompanied by a reference to a standards-track or
>    Informational RFC or by a reference to published cryptographic or
>    mathmatical literature which describes the new type.
> 
> Group Description (Value 4) -> RFC required
> Group Type (Value 5) -> Specification required
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Life Type (Value 11)
> Current: Specification Required
> RFC2409: 11.5 Life Type
> 
>    Values of the Life Type Class define a type of lifetime to which the
>    ISAKMP Security Association applies. Requests for assignment of new
>    life types must be accompanied by a detailed description of the units
>    of this type and its expiry.
> 
> -> Hmm... this is vague, I would expect it means "Specification
>    required", so ok already.
> 
> ----------------------------------------------------------------------
> 
> Registry Name: PRF (Value 13)
> Current: Standards-track or Informational RFC
> 
> There is nothing about this in the RFC2409, so I would say either "RFC
> required" or "Specification required" would be ok. 
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Exchange Type
> Current: Not defined
> 
> There is nothing in RFC2409/RFC2408. There has not been additions to
> this, and I do not expect there to be one (as all new stuff should be
> done on the protocol which obsoleted this one). I would say "Standards
> Action" would most likely be best for this.
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Additional Exchanges Defined-- XCHG values
> Current: Not defined
> 
> There is nothing in RFC2409/RFC2408. Same as above -> "Standards
> Action". 
> 
> ----------------------------------------------------------------------
> 
> Registry Name: ISAKMP Domain of Interpretation (DOI)
> Current: Standards-track RFC
> RFC2408: Domain of Interpretation
> 
>    The Domain of Interpretation (DOI) is a 32-bit field which identifies
>    the domain under which the security association negotiation is taking
>    place.  Requests for assignments of new DOIs must be accompanied by a
>    standards-track RFC which describes the specific domain.
> 
> -> "Standards action" (i.e. Standards-track RFC)
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Next Payload Types
> Current: Internet Draft
> 
> There is nothing in RFC2409/RFC2408. There has been more of these, so
> "RFC required", I think Internet Draft is bit too low, and not
> matching the RFC5226 usages.
> 
> ----------------------------------------------------------------------
> 
> Registry Name: Notify Message Types
> Current: Not defined
> Sub-registry: Notify Messages - Error Types (1-8191)
> Current: Not defined
> Sub-Registry: Notify Messages - Status Types (16384-24575)
> Current: Not defined
> 
> No additions to these registries, but these are large registries, so
> perhaps "RFC required".
> 
> ----------------------------------------------------------------------
> 
> There is a problem in the "IPSEC Authentication Methods (Value 3)" as
> there is 3 values which do not have any real specification, i.e.
> 
> 6             Encryption with El-Gamal	
> 7             Revised encryption with El-Gamal	
> 8             ECDSA signatures                        [Fahn]
> 
> As there is no reference to any document or anything, I have no idea
> how anybody could actually implement those in interoperable manner. I
> would suggest changing those to:
> 
> 6             Reserved (was Encryption with El-Gamal)
> 7             Reserved (was Revised encryption with El-Gamal)
> 8             Reserved (was ECDSA signatures)
> 
> so it is clear that nobody knows how those should be implemented...
> 
> ----------------------------------------------------------------------
> 
> > 2) I've added the draft ietf-ipsec-ike-ecc-groups to ipsec-registry.
> > I then noticed that the document also requests the following values
> > as described in Table 2 in the IANA Considerations section:
> > 
> > 6 EC2NGF163Random2
> > 7 EC2NGF163Koblitz
> > 8 EC2NGF283Random
> > 9 EC2NGF283Koblitz
> > 10 EC2NGF409Random
> > 11 EC2NGF409Koblitz
> > 12 EC2NGF571Random
> > 13 EC2NGF571Koblitz
> 
> These are from the
> http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version,
> i.e. the registry was updated at some point in 2002 even when the
> registry had registration policy of "RFC Required" and the document
> was still draft (and was never published as RFC).
> 
> I think you should remove "Panjwani" and "Blake-Wilson" and put
> "ipsec-ike-ecc-groups" for all of them, and put some down a footnote
> saying that the registry was updated too early and the draft never
> made it to the RFC, but as these values might be used by some
> implementations they are left there in the registry, but new
> implementations should not use them. Also the reference could point
> out that the values in the registry match the -04 version of the
> document.
> 
> > 22 ECPRGF192Random
> > 23 EC2NGF163Random
> > 24 ECPRGF224Random
> > 25 EC2NGF233Random
> > 26 EC2NGF233Koblitz
> 
> These overlap with the already allocated other groups, so those should
> not be added to the registry. 
> 
> > Question: are these, specifically 10-13 & 22-26, no longer required
> > by ietf-ipsec-ike-ecc-groups?  If we should leave them untouched,
> > please let me know.
> 
> The draft-ietf-ipsec-ike-ecc-groups document will most likely not be
> going forward so adding the footnotes and comments to references might
> be best. 
> 
> I did not yet check the isakmp-registry, I will do that later. 
> 

~pearl

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 09 Feb 2012 19:59:46 +0200

Hi Pearl, Tero,

Regarding the first change (IPsec Auth Methods), I prefer the existing 
language. Even though IKEv1 has been obsoleted, I think change control 
of this central piece of the protocol needs to still require a higher 
bar than just "specification required".

I'm afraid my co-chair disagrees, but he can surely speak for himself...

Thanks,
	Yaron

On 02/08/2012 04:07 AM, Pearl Liang via RT wrote:
>>> Question: are these, specifically 10-13&  22-26, no longer required
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Feb 2012 10:10:02 -0800

On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote:

> Hi Pearl, Tero,
> 
> Regarding the first change (IPsec Auth Methods), I prefer the existing language. Even though IKEv1 has been obsoleted, I think change control of this central piece of the protocol needs to still require a higher bar than just "specification required".
> 

I do, and I can. The overhead of requiring IETF and RFC Editor process for extensions to a popular-but-obsolete protocol is not worth it. If someone publishes a new authentication mechanism for IKEv1 that has significant flaws (and they certainly will), they publish a new document and it gets a new identifier. This will damp out fairly quickly, and auth mechanism developers will get more input before publishing.

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Feb 2012 15:13:15 +0200

> registration procedures at this time?  

As there seems to be different opinions about this in the IPsecME WG,
I think it might be better to leave this for now, and then we can work
on that issue by using the draft-harkins-ike-iana-update document as
our placeholder.

I myself do think that as the current Standards-track RFC requirement
is not mentioned in any RFCs, we do not necessarely need RFC to change
it (and I think publishing RFC just to change one unspecified
registration policy is not really needed).

On the other hand we do need to have concencus on the issue among the
working group, so after we reach that, we can come back to you,
regardless whether we publish separate document about that issue or
not (which is separate issue we need to decide).

So leave it as it is for now, and we work on this issue in the IPsecME
WG. 

> Question2: Would it be sufficient to list "RFC required" only?

Yes that would also be acceptable, but "Specification required" would
be more inline with other cryptographic algorithms specified in the
RFC2409 (encryption algorithm, hash algorithm etc), so I would prefer
"Specification required".

The exact text in RFC2409 for similar registries is:

   Requests for assignment of new encryption algorithm values must be
   accompanied by a reference to a standards-track or Informational
   RFC or a reference to published cryptographic literature which
   describes this algorithm.

> - For these 'early assignment' registrations as per
> ietf-ipsec-ike-ecc-groups, you commented the following:
> 
> > > 6 EC2NGF163Random2
> > > 7 EC2NGF163Koblitz
> > > 8 EC2NGF283Random
> > > 9 EC2NGF283Koblitz
> > > 10 EC2NGF409Random
> > > 11 EC2NGF409Koblitz
> > > 12 EC2NGF571Random
> > > 13 EC2NGF571Koblitz
> > 
> > These are from the

That note seems to be ok.

> Please see: http://www.iana.org/assignments/ipsec-registry

Your changes seem to be ok.

BTW, is there any way to get diffs to the registries, in the same way
you can get diffs to the drafts. It would be useful when checking out
what has changed in the registry and when.

Do you keep old versions of the registries and if so, is there a way
to fetch those using http so I could use rfcdiff (or wdiff, or make
separate tool for that) to make side by side diffs of the registries.

> When you have updates for the isakmp-registry, please send them

I will come back when I have time to go through that one.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Feb 2012 15:23:01 +0200

[Removed iana etc from the CC list, as there is no point of keeping
them spammed by our WG discussion, I will contact back to them when we
have some kind of resolution about this.]

Paul Hoffman writes:
> > Regarding the first change (IPsec Auth Methods), I prefer the
> > existing language. Even though IKEv1 has been obsoleted, I think
> > change control of this central piece of the protocol needs to
> > still require a higher bar than just "specification required". 
> > 
> I do, and I can. The overhead of requiring IETF and RFC Editor
> process for extensions to a popular-but-obsolete protocol is not
> worth it. If someone publishes a new authentication mechanism for
> IKEv1 that has significant flaws (and they certainly will), they
> publish a new document and it gets a new identifier. This will damp
> out fairly quickly, and auth mechanism developers will get more
> input before publishing. 

I think I agree with Paul, but I am not completely sure I understood
what he was saying above... :-)

Anyways, I think Specification required should be enough for that
registry. Other option would really be "Obsoleted protocol, no
allocations allowed", but that would upset even more people...

I do not really see that much point of requiring people to try to get
standard track RFC out just to update the registry, when otherwise the
document could be informational or just specified in some other
standards body etc.

The end result will most likely going to be that people pick number
and start using it without bothering to allocate number for it all, if
the allocating number is too hard. And getting standards track
document to update already obsoleted protocol is going to get other
people complaining (including me).

As this is the last item in the iana ipsec-registry cleanup, I would
like to get this to agenda for example for the Paris meeting and
discuss this there and make decision (one way or other) and solve this
after the Paris meeting.

So my question to working group chairs, would that be ok to discuss
this in Paris IETF meeting (depending of course whether we have
session there or not), and I would like people to hear any other
comments about this here in the mailing list anyways. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 10 Feb 2012 22:13:25 +0200

Hi Paul,

sorry, I don't understand your statement. Yes, IKEv1 is popular but 
(formally) obsolete. It is still our responsibility to ensure that it 
doesn't gain new and insecure extensions in its old age. The way we do 
it is through the normal IETF/RFC-Ed/IANA bureaucratic processes.

Unlike Tero, I don't think people will be adding non-IETF extensions of 
this sort to IKEv1. New crypto algorithms, maybe. But new authentication 
methods? I'd be surprised.

I'm fine with Tero's proposal to resolve this question in Paris.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 12:35:27 -0800

On Feb 10, 2012, at 12:13 PM, Yaron Sheffer wrote:

> sorry, I don't understand your statement. Yes, IKEv1 is popular but (formally) obsolete. It is still our responsibility to ensure that it doesn't gain new and insecure extensions in its old age.

I think you understand my statement but simply disagree with it. :-) I don't believe that is our responsibility, although we can certainly help prevent it if the extension writers ask us. If an extension writer creates an insecure extension, we can point that out, make fun of it on the mailing list and in the press, and so on; it is not our responsibility to prevent it for an obsolete protocol.

> The way we do it is through the normal IETF/RFC-Ed/IANA bureaucratic processes.

Yes.

> Unlike Tero, I don't think people will be adding non-IETF extensions of this sort to IKEv1. New crypto algorithms, maybe. But new authentication methods? I'd be surprised.

We are often surprised.

> I'm fine with Tero's proposal to resolve this question in Paris.

I would rather hear much more before then, and maybe even come to agreement. If we need to have a voice discussion, we could have an open design team meeting related to this in a week or so.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 10 Feb 2012 14:45:15 -0800 (PST)

> methods? I'd be surprised.

  SURPRISE! It's me. And I want to add a new authentication method
to IKEv1. New, yes; insecure, no. In fact, it makes things _more_ secure
because it obviates the need for insecure extensions that have been added
to IKEv1 and widely implemented, like XAUTH, because it removes the
requirement that a PSK be bound to an IP address and it is resistant to
dictionary attack.

  (And now that I have mentioned this, will you be surprising yourself
by proposing a new authentication method for IKEv1 that is resistant to
dictionary attack?)

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Feb 2012 15:02:42 +0200

Hi Dan,

No surprise at all - I used the term "non-IETF extension". As long as 
your extension goes through proper IETF process/review, I'm fine with 
it. I might even support it, since I agree that it adds security to 
IKEv1/PSK. Other people might argue that we shouldn't confuse the 
industry by adding major new pieces to IKEv1.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 12 Feb 2012 18:34:39 +0200

> industry by adding major new pieces to IKEv1.

Does that mean thay you would accept "IETF Review", when allocating
new authentication method, but you would NOT accept "specification
required" (or "RFC required", as that include also RFC Editor
Independent submission). 

The "IETF REview" do have proper IETF processes, altought a bit less
than what is for required for "Standards Action.

I assume the "Standard-track RFC" in the registry actually mean
"Standards Action" in the RFC5226 language.

The text for IETF Review from the RFC5226 says:

----------------------------------------------------------------------
      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.
----------------------------------------------------------------------

Would that be acceptable for you?

Would that be acceptable for others?

That would be acceptable for me, as I just want something bit easier
than current "Standard-Track RFC", i.e. I do not want to add new
Standards to the IKEv1...
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Feb 2012 23:53:10 +0200

Hi Tero,

yes, the text you quote on IETF Review is acceptable to me. I am 
basically looking for a process that will allow members of this WG to 
opine on:

- Whether the spec is technically sound, interoperable etc.
- Whether the spec is secure.
- Whether it is appropriate to add it to IKEv1 (i.e. the spec would not 
damage adoption of IKEv2 and would not create future issues around 
migration to IKEv2).

These goals are provided by the IETF Review process as defined in 5226, 
but not by the "lower" criteria.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 14:24:18 -0800

On Feb 13, 2012, at 1:53 PM, Yaron Sheffer wrote:

> yes, the text you quote on IETF Review is acceptable to me. I am basically looking for a process that will allow members of this WG to opine on:
> 
> - Whether it is appropriate to add it to IKEv1 (i.e. the spec would not damage adoption of IKEv2 and would not create future issues around migration to IKEv2).
> 
> These goals are provided by the IETF Review process as defined in 5226, but not by the "lower" criteria.

I still find this to be too heavy-weight for my tastes, but I may be the only one who thinks so.

--Paul Hoffman

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 16 Feb 2012 18:48:40 +0000

Hi, Tero,

Thank you for the reply.  Please see comments marked with [pl].

> So leave it as it is for now, and we work on this issue in the IPsecME

[pl] No action.

>    describes this algorithm.

[pl] I changed the reg procedures to "Specification required" for 
the sub-registry 'PRF' at http://www.iana.org/assignments/ipsec-registry.

> > Please see: http://www.iana.org/assignments/ipsec-registry
[pl] Done.  I'll submit this for conversion to XML as the source. 
If you see any errors, please let us know.

> separate tool for that) to make side by side diffs of the registries.

[pl] we do not offer this at this time, however we can consider 
what you have proposed when developing improvements to the website,
which is in process right now.

> I will come back when I have time to go through that one.

Okay.  Thank you.

Best,
~pearl