On 09/02/2021 07:39, Ulrich Windl wrote:
Dhruv Dhody <dhruv.ietf@xxxxxxxxx> schrieb am 08.02.2021 um 18:05 in
Nachricht
<CAB75xn7tXa1BCHd=KFR9DC=+bA01R1A+X2M4oUbrF-YLx8ExJA@xxxxxxxxxxxxxx>:
Hi Tom,
Thanks for your detailed review. Lets discuss the security first ‑
On Mon, Feb 8, 2021 at 6:07 PM tom petch <daedulus@xxxxxxxxxxxxx> wrote:
This is my second response to this Last Call, about a possible security
issue.
RFC8573 seems clear that MD5 must not be used to effect security for NTP
but this I‑D imports iana‑crypt‑hash which allows MD5 without any
restriction, so is MD5 allowed or not?
Good question. While it is easy to restrict the use of MD5 by adding a
must statement, I want to check if it is a good idea. The YANG model
is written in such a way that it supports older versions of NTP as
well. Would barring MD5 configuration be an issue if there are older
implementations in the network still? I think perhaps adding a warning
in the description is a good idea. I did a quick search and dont see
other YANG models doing a check either. Would be good to get some
guidance on this.
I just checked the docs of a recent ntpd: The docs say DES was replaced with
MD5, but they do in no way say that MD5 is obsolete.
For example the docs (man ntp.conf) say:
FILES
/etc/ntp.conf the default name of the configuration file
ntp.keys private MD5 keys
Ulrich
The issue here is what the IETF is willing to give consensus for, as
opposed to what is out in the field. For some years now, the IETF has
deprecated the use of MD5 (even though there are contexts in which it is
still strong enough) so the point of my post was to flag to those in the
IETF who are concerned with security, such as Security ADs, that this
I-D places no constraint in the YANG on the use of MD5. I think that
that will not gain consensus and that changes will be needed, either in
the Security Considerations or the YANG or both.
Tom Petch
Regards,
Ulrich
There are features defined which allow the hash in iana‑crypt‑hash to be
restricted but this I‑D does not use them.
I didn't see any reason to use them in the NTP Yang. Can you?
Probably iana‑crypt‑hash should be updated ‑ I will raise that on the
NETMOD WG list.
The I‑D also uses MD5 in a way that would appear not to be security
related, to hash an IPv6 address.
This is as per RFC 5905 ‑
If using the IPv4 address family, the identifier is the four‑
octet IPv4 address. If using the IPv6 address family, it is the
first four octets of the MD5 hash of the IPv6 address.
In passing, this I‑D has three references to RFC7317. This is wrong ‑
the module is IANA‑maintained and so the references should be to the
IANA website.
But even the iana‑crypt‑hash YANG model put RFC 7317 as a reference ‑
revision 2014‑08‑06 {
description
"Initial revision.";
reference
"RFC 7317: A YANG Data Model for System Management";
}
I will start working on your other comments and prepare a new version.
Thanks!
Dhruv
The secdir reviewer might be interested in my thoughts.
Tom Petch
On 29/01/2021 22:39, The IESG wrote:
The IESG has received a request from the Network Time Protocol WG (ntp)
to
consider the following document: ‑ 'A YANG Data Model for NTP'
<draft‑ietf‑ntp‑yang‑data‑model‑10.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
last‑call@xxxxxxxx mailing lists by 2021‑02‑12. Exceptionally, comments
may
be sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.
Abstract
This document defines a YANG data model for Network Time Protocol
(NTP) implementations. The data model includes configuration data
and state data.
_______________________________________________
ntp mailing list
ntp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ntp
.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
