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 protected] wrote: > [I CCed the [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
