>>> 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
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
