[Ntp] Antw: Re: Adam Roach's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

>>> Kyle Rose <krose@krose.org> schrieb am 21.11.2018 um 19:01 in Nachricht
<CAJU8_nUV+m-7f+1gLD4Uu__sNnkT1MTpY62hO2CmRLT2=N1Lmw@mail.gmail.com>:
> I think the objection about backwards compatibility is more easily
> addressed by noting that deployments currently using MD5 authentication
> have a pre-existing relationship that presumes the existence of pre-shared
> keys and an implied agreement on MD5. If a new version of the software
> allows for selection of the MAC algorithm on a per keyid basis, then there
> is a natural rollout path that does not require an atomic upgrade of all
> servers in a cluster. (keyid here refers to section 7.3 of RFC 5905.)
> 
> So, one potential rollout option is to upgrade all NTP servers in a mutual
> trust network, keeping the existing keyid, key, and algorithm (MD5) but
> adding an additional keyid, key, and algorithm (AES-CMAC). Once the
> software upgrade is complete, alter the servers' configurations to use the
> new keyid. This kind of two-phase commit is less flexible than online
> negotiation of cipher suites, but it seems fine given the constraints of an
> existing wire image and the need to be backwards-compatible. I have not
> looked at either the code or the config to know if the necessary degree of
> algorithmic agility is currently supported, but I can't imagine it would be
> difficult to add.

Hi!

It's not related to the draft, but, there is no command to _easily_ change the key of a server/peer only, meaning one must drop the  assoc and reestablish a new one. That means a temporary drop of quality from that assoc. Maybe the reference implementation could add some command like "usekey <keynumber> <assoc>..." that would also allow to add a key where no one existed before...

Regards,
Ulrich
P.S. CC list trimmed somewhat.

> 
> Other use cases should look to NTS.
> 
> Kyle
> 
> On Tue, Nov 20, 2018 at 3:08 PM Hal Murray <hmurray@megapathdsl.net> wrote:
> 
>>
>> > I agree with Mirja's concerns about the backwards compatibility aspects,
>> > especially from an operational perspective -- in particular, is there
>> some
>> > way to roll this change out incrementally, or does it require a flag
>> day? It
>> > seems to me that this document really needs an "operational
>> considerations"
>> > section that either explains how this change might be deployed or cites
>> some
>> > already existing NTP document that does so.
>>
>> No flag day.  The config files specify the crypto algorithm.  Current code
>> supports MD5 and SHA1.   AES128CMAC gets added.
>>
>> If you are thinking about that area, I'd worry about the opposite.  As far
>> as
>> I can tell, crypto isn't used much.  News about a new RFC isn't likely to
>> get
>> to the admins who are actually in charge of the machines using it so they
>> will
>> continue to use whatever they are currently using.
>>
>>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
>>