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
