On 30/10/2020 22:42, Tero Kivinen wrote:
Roman Danyliw writes:
It seems to me that the IANA entries for IKEv2 are incomplete.
RFC8247 does a fine job of specifying algorithms and adding
information such as status (MUST/SHOULD+), IoT, AEAD and so on,
information which is not present on IANA. The policy for, e.g.
Transform Type 1, is expert review and entries have been added via
draft-smyslov-esp-gont but the IANA entries lack this information
and, looking at the I-D, I see no such information (nor is there any
reason for it to be there). Yet draft-ietf-i2nsf-sdn... needs
this information as references in the YANG module show.
I am lost what information is missing from the IANA registry.
Tero
Thanks for getting back to me. What is missing from the IANA registry
is the guidance as to the status of the algorithm, how highly it is
recommended or not. This I-D tells people to go to RFC8247 and the IANA
Registry for advice; RFC8247 gives that advice; the IANA web page does not.
And RFC8247 specifies which algorithm are AEAD, the web page does not.
The YANG module behaves differently depending on whether or not the
algorithm is AEAD; YANG implementors need to know, having this
information on the web page would make it easier for YANG implementors.
And RFC8247 specifies IoT, which I do not think is yet a consideration here.
As I said, we are currently ok but as new algorithms get added, by
Expert Review, then that information is needed and may not be available
as there is no requirement for the Expert Reviewer to make it available.
As I said to Roman, the TLS WG found that they needed to add extra
columns to their web pages of algorithms. Different columns (e.g. DTLS
not AEAD) but I think that the situation is otherwise identical so I am
anticipating that in a year or two you will see what I mean:-). In
passing, the TLS WG determine by consensus what the status is for a new
algorithm but the Expert Reviewer makes it available via the web site
whether or not it is in an RFC.
I take your point about duplicating data - no relational databases here!
- but the answer is to specify which is authoritative and for me that
should be the IANA pages as it is for many assignments in the context of
YANG and before that SMI going back decades.
Tom Petch
The
registry do include numbers from draft-smyslov-esp-gost document. The
RFC8247 says:
----------------------------------------------------------------------
1.3. Updating Algorithm Requirement Levels
...
.... As a result, any algorithm listed at the IKEv2
IANA registry not mentioned in this document MAY be implemented.
----------------------------------------------------------------------
I.e., all algorithms not listed there are MAY to implement.
But I do not see any reason why the yang module should provide any
other than pointer to the IANA registry, and the IANA registry already
has pointer to the RFC8247 to indicate the requirement levels for
algorithms.
It seems to me that this is a similar situation to that which the TLS
WG found itself in and which led to a revision of the TLS IANA
entries to provide what was needed via additional columns.
There was some requests to modify the IANA registry while we were
publishing RFC 8247 and the WG decided against it, and instead decided
to provide pointer to the RFC 8211 and RFC 8247 in the notes section.
The reason for that is that duplicating information always causes
problems, and because there is no (public) history of the IANA
registries, there is no way of finding out when and why specific
change to the registry was done unless there happens to be RFC that
actually did that change.
I myself as an IANA expert of those registries do think it is better
that working group will do RFC that will update the levels, and that
will leave audit trail and public working group mailing list
discussion about the changes.
I think that the IANA pages for IKEv2 need revising so that that
additional information that RFC8247 provides is required as
additional columns in the IANA entries at least for Type 1, Type 2,
Type 3, Type 4 and Authentication Method.
I fail to see why does that information need to be in the IANA
registry? This is YANG model for IPsec, it should just refer to the
IANA registry about the mapping from algorithms to numbers and other
way around, but whether the algorithm is recommended or not, does not
belong to the YANG model, as that is not something that can be
modified by configuration or be part of running state.
This document seems to have wierd text in it:
typedef encryption-algorithm-type {
type uint16;
description
"The encryption algorithm is specified with a 16-bit
number extracted from IANA Registry. The acceptable
values MUST follow the requirement levels for
encryption algorithms for ESP and IKEv2.";
I do not see what the last sentence of the text is trying to say? Does
it mean that this yang model cannot be shown of running configuration
where someone is using one the algorithms not considered safe anymore?
In ietf we usually just try to say what implementors are implementing,
we do not that often limit what adminstrators can configure. If the
implementation happens to implement one of those weak ciphers for
example for talking to one obsoleted old hardware that only supports
them, then I do not see why this yang model should forbid showing
running status of such configuration.
I think this document should just say that the algorithm numbers are
from the IANA registry, and nothing more. There might be informal
reference to the RFC 8221, and RFC 8247 but even that should not be
needed, as anybody implementing IKEv2 or ESP will already follow those
and only implement the algorithms from there that they seem proper. In
some cases that selection might include algorithms which are on SHOULD
NOT or even MUST NOT, if the backward compatibility to obsolete
hardware is more important than conformance.
This I-D, as you quote, points to RFC8247 for guidance and that is
fine. But security moves on and new algorithms will be needed and
this I-D also points to the IANA registry, which is Expert Review,
where new entries have been added already; and for those the IANA
Registry gives no guidance and the I-D that IANA references for
the new entries - written by the Expert Reviewer! - also gives no
guidance. Over time we are likely to accrue algorithms with no
guidance unless and until an RFC8247-bis appears or we require
IANA to have columns for guidance. Currently the new algorithms
are GOST and so perhaps of limited interest but on the TLS list I
am always seeing new algorithms appear and there the new IANA
entry is required to give guidance. My sense is that IKEv2 is a
bit slower to take up new ones but, as with RFC8247, it does
eventually.
The original cryptographic algorithm impelemtation requirements for
ESP and AH was published as RFC4305 in 2007. It was replaced with
RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2
we skipped the 2014 update, as that was not needed. We do have plans
to keep that draft up to date, and update it when there is need for
that, most likely in next 5 years or so, provided that implementation
status of some of new algorithms progresses favorably.
I think that users need those extra columns that RFC8247 provides
on the IANA website so that when new algorithms are added by
Expert Review, then that guidance must be added as well. This is
what the TLS WG came round to and I think that IKEv2 needs to do
the same.
I as an Expert does not want to decide whether the individual request
to add new 3rot13 cipher to the IANA registry should be MUST NOT,
SHOULD NOT, MAY or what. If the field is in the IANA registry then
whoever requests to add information to there can request whatever
value they want for that field too. Of course as an IANA expert I can
reject that by saying that 3rot13 is not MUST, but it is MUST NOT
algorithm, and then we can have discussion about that.
I rather have that discussion in the working group when we are
updating the requirements document next time. And as I said IANA
registries do not have any (public) history, or any way of finding out
why they got changed and who did the change. There has happened some
changes in the registry where I as an IANA Expert was not aware of at
all...
And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or when
some of those earlier algorithms was renamed, I need to go to my
private mail archives.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
