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

[Yaron Sheffer <[e-mail]>]

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:
> 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, [e-mail] wrote:
>> [I CCed the [e-mail] 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
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec