Subject: [IPsec] Extra note to IKEv2 Transform registries

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jan 2019 16:39:07 +0200

Talking as IANA expert, I am planning to send following email to iana.
We did discuss this in the Bangkok IETF, and as an IANA export for the
IKEv2 registries think this is much better idea, than to copy the
recommendations from the RFC8221 an RFC8247 to the iana registry.

Does anybody have any comments or objections of doing this?

The Note will be part of the per registry header in the IANA page. An
example can be seen in the "IKEv2 Configuration Payload Attribute
Types" registry, which has note which explains the meaining of "*" in
Multi-Valued column.

Email to be sent to [email-masked] next week:
----------------------------------------------------------------------
In Bangkok we discussed that I would like to put reference to RFC8221
and RFC8247 to IKEv2 cryptographic algorithms registries. This would
include notes as follows:

--

In "Transform Type 1 - Encryption Algorithm Transform IDs" of
"Internet Key Exchange Version 2 (IKEv2) Parameters" add note as
follows:

	To find out requirement levels for encryption algorithms for
	ESP see RFC 8221, and for IKEv2 see RFC 8247.

--

In "Transform Type 2 - Pseudorandom Function Transform IDs" of
"Internet Key Exchange Version 2 (IKEv2) Parameters" add note as
follows:

	To find out requirement levels for PRFs for IKEv2 see RFC
	8247.

--

In "Transform Type 3 - Integrity Algorithm Transform IDs" of "Internet
Key Exchange Version 2 (IKEv2) Parameters" add note as follows:

	To find out requirement levels for encryption algorithms for
	ESP/AH see RFC 8221, and for IKEv2 see RFC 8247.

--

In "Transform Type 4 - Diffie-Hellman Group Transform IDs" of
"Internet Key Exchange Version 2 (IKEv2) Parameters" add note as
follows:

	To find out requirement levels for Diffie-Hellman groups for
	IKEv2 see RFC 8247.

--

In "IKEv2 Authentication Method" of "Internet Key Exchange Version 2
(IKEv2) Parameters" add note as follows:

	To find out requirement levels for IKEv2 authentication
	methods see RFC 8247.

--

In "IKEv2 Notification IPCOMP Transform IDs (Value 16387)" of
"Internet Key Exchange Version 2 (IKEv2) Parameters" add note as
follows:

	To find out requirement levels for IPCOMP methods see RFC
	8221.

--

In "IKEv2 Hash Algorithms" of "Internet Key Exchange Version 2 (IKEv2)
Parameters" add note as follows:

	To find out requirement levels for IKEv2 hash algorithms see
	RFC 8247.

-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Jan 2019 10:08:55 -0500 (EST)

> 	To find out requirement levels for PRFs for IKEv2 see RFC

Requirement for what? I don't think the IANA reader will know these
are vendor build support requirements, and not default case runtime
requirements ?

I don't object, but I obviously think it is better for implementers
to be able to look at the IANA registry with clickable references
to the RFC that obsoleted/deprecated an algorithm.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jan 2019 20:55:57 +0200

> are vendor build support requirements, and not default case runtime

Iana registry is only for vendors, normal users should ever need to
check them ever.

Why would some user need to know that PRF_HMAC_SHA1 maps to number 2
on the wire? Only vendors need that information. If users require that
information there is something seriously wrong with the user interface
of the implementation.

Anyways RFC8247 do explain that already:

1.4.  Document Audience

   The recommendations of this document mostly target IKEv2 implementers
   who need to create implementations that meet both high security
   expectations as well as high interoperability between various vendors
   and with different versions.  Interoperability requires a smooth move
   to more secure cipher suites.  This may differ from a user point of
   view that may deploy and configure IKEv2 with only the safest cipher
   suite.

   This document does not give any recommendations for the use of
   algorithms, it only gives implementation recommendations regarding
   implementations.  The use of algorithms by a specific user is
   dictated by their own security policy requirements, which are outside
   the scope of this document.

If we add any recommendations for algoritms in the IANA registry we
would also need to include such explination there and I do not think
we want to copy RFC8247 to iana registry. 

> to the RFC that obsoleted/deprecated an algorithm.

Sure. Write draft-ietf-ipsecme-ikev2-des-md5-die-die-die and we can
use that RFC number for them.

Or we can change the reference column for those to point to
RFC8221/RFC8247 for those where they say it is MUST NOT.
That is something that is easy to do with just sending request to
iana.

Earlier I understood that you wanted to add some new column there
which would add new information that is copied from RFC8221/8247.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Jan 2019 14:38:24 -0500 (EST)

> Iana registry is only for vendors, normal users should ever need to

Fair enough.

> That is something that is easy to do with just sending request to

Either works, that was what we were trying to do :)

> which would add new information that is copied from RFC8221/8247.

No, just having the registry confirm which things you should not
implement is what I was looking for. Although there is one important
difference with 8221/8246, which is what to do with MAY algorithms
that we found no strong reason for to MUST NOT, but which should really
be retired too. Like CAST for example. But I guess formally, a bis
document should move those MAY's to MUST NOT.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Jan 2019 22:24:17 +0200

> Either works, that was what we were trying to do :)

Ok, then I misunderstood what people were saying earlier, I understood
some people wanted to have similar new column that TLS had..

> document should move those MAY's to MUST NOT.

Ok, so the following change would be better:

--

Also as RFC8221 and RFC8247 marked some of those documents as MUST
NOT, we need to change the reference for those algorithms to refer to
those documents instead of the original documents. I.e., change
following algorithm references as follows:

       		 	   ESP Reference	IKEv2 reference
   ENCR_DES_IV64	   [RFC8221]		-
   ENCR_DES		   [RFC8221]		[RFC8247]
   ENCR_BLOWFISH	   [RFC8221]		[RFC7296]
   ENCR_3IDEA	   	   [RFC8221]		[RFC7296]
   ENCR_DES_IV32   	   [RFC8221]		-

I.e., for all of those algorithms change the ESP refence to RFC8221
which marks those algorithms as MUST NOT for ESP, and for ENCR_DES
change the refence for IKEv2 to RFC8247. For ENCR_DES_IV64,
ENCR_BLOWFISH, ENCR_3IDEA and ENCR_DES_IV32 keep the IKEv2 references
as they are now.

--

Also as RFC8247 marked PRF_HMAC_MD5 as MUST NOT, we need to change the
reference for that to refer to RFC8247 instead of the original
documents. I.e., change following algorithm references as follows:

       		 	   Reference
   PRF_HMAC_MD5	   	   [RFC8247]

--

Also as RFC8221 and RFC8247 marked some of those documents as MUST
NOT, we need to change the reference for those algorithms to refer to
those documents instead of the original documents. I.e., change
following algorithm references as follows:

       		 	   Reference
   AUTH_HMAC_MD5_96	   [RFC8221][RFC8247]
   AUTH_DES_MAC		   [RFC8221][RFC8247]
   AUTH_KPDK_MD5	   [RFC8221][RFC8247]

--

Also as RFC8247 marked some of those algorithms as MUST NOT, we need
to change the reference for those algorithms to refer to RFC8247
instead of the original documents. I.e., change following algorithm
references as follows:

							   Reference
   768-bit MODP Group					   [RFC8247]
   1024-bit MODP Group with 160-bit Prime Order Subgroup   [RFC8247]

--

--

Also as RFC8221 marked IPCOMP_OUI as MUST NOT, we need to change the
reference for that to refer to RFC8221 instead of UNSPECIFIED. I.e.,
change following algorithm references as follows:

		   Reference
   IPCOMP_OUI      [RFC8221]

--

Also as RFC8247 marked SHA1 as MUST NOT, we need to change the
reference for that to refer to RFC8247 instead of the original
documents. I.e., change following algorithm references as follows:

       		 	   Reference
   SHA1		   	   [RFC8247]

-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Jan 2019 15:35:56 -0500 (EST)

> some people wanted to have similar new column that TLS had..

But your proposed changes does not add "obsolete" or "deprecated" to
the IANA registry entries?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Jan 2019 22:57:39 +0200

> the IANA registry entries?

No. Only change the reference to the document that says those
algorithms are MUST NOT. You wanted clickable link to document that
will tell the status. This results in what you asked for....

Having obsolete or deprecated in reference column in addition to the
RFC8221/8247 reference would be bigger change, and then I think
die-die-die document would be better reference and that document could
ask IANA to make the changes.
-- 
[email-masked]