Re: [Ntp] [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 23:48, Benjamin Kaduk wrote:
> On Mon, Feb 15, 2021 at 05:36:46PM +0000, tom petch wrote:
>> 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.
>
> I would mostly have expected the MD5 authentication option to be split off
> into a separate YANG module that aguments the base one, or maybe hidden
> behind a YANG feature, in order to give implementations the ability to "do
> the right thing" (that is, expose only the modern crypto) while remaining
> compliant with the primary YANG module.  As far as I know, either of those
> options would still make it pretty trivial to also expose the MD5
> functionality for legacy compatibility (which is in some different sense
> also "the right thing to do", at least for now), but would make it clear
> that it's not endorsed by the IETF to the same level.

Ben

Thank you for the suggestions.  I will pursue it with Dhruv and see what 
he wants to do.  YANG feature would seem the simpler option to me but 
either sound fine.

Tom Petch

> -Ben
> .
>