Re: [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity

[tom petch <[e-mail]>]

On 15/02/2021 01:11, Benjamin Kaduk wrote:
> Hi Tom,
>
> On Tue, Feb 09, 2021 at 10:23:57AM +0000, tom petch wrote:
>> On 08/02/2021 17:05, Dhruv Dhody wrote:
>>> Hi Tom,
>>>
>>> Thanks for your detailed review. Lets discuss the security first -
>>>
>>> On Mon, Feb 8, 2021 at 6:07 PM tom petch <[e-mail]> 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.
>>
>> Dhruv
>>
>> After many years, Security (AD, secdir, advisor) still have the power to
>> surprise me but I would still be surprised if Security were happy with
>> an I-D which places no constraint on MD5 when the IETF has published RFC
>> deprecating its use and NTP has RFC8573 which specifically deprecates it.
>>
>> Yet Security may not realise this from reading this I-D since the
>> unrestricted use of MD5 is not immediately apparent so my post was aimed
>> at bringing this to the attention of Security.  As to whether this needs
>> a note in Security Considerations or enforcing by YANG or both I am less
>> clear on - that is up to Security.  If the YANG is to deprecate it, then
>> the features in ianach make that possible.
>>
>> Whether or not MD5 is widely used in the field is irrelevant.  The IETF
>> consensus it to deprecate its use and I am sure that the IESG will want
>> this I-D to do just that.
>
> Thanks for flagging the issue; it's good to have many eyes looking out for
> these things.
>
> That said, I think recent practice has been to not take a strict hard line
> that MD5 cannot be used ever, and that non-cryptographic uses for legacy
> compatibility can be retained, when accompanied by a disclaimer that the
> use of MD5 is not for cryptographic purposes and that MD5 is not a secure
> cryptographic hash function.
>
> There is an example of this buried in my remarks at
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ballot/ that
> resulted in the text now found at
> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-29#section-11.6 .

Ben

Thank you for noticing:-)
The -10 that I reviewed had
- MD5 is used to turn an IPv6 address into a 32-bit identifier
- MD5 can be used for authentication without constraint
- AES-CMAC cannot be used for authentication.
I do not have a view on the first but see the second and third as 
contradicting RFC8573 and so in need of change.  Allowing AES-CMAC I see 
as not controversial but do not have a view as to what to do with MD5 
used for authentication e.g.
- allow without constraint
- allow, but deprecated, in the YANG
- allow with a note in Security COnsiderations
- do not allow in the YANG
etc.
I am still sitting on the fence on that issue, lacking the secuirty 
insight as to what would be acceptable, to you and the IESG.

Tom Petch


> -Ben
> .
>