Subject: [Ntp] Feedback on draft-aanchal4-ntp-mac

From: Harlan Stenn <[email-masked]>
Date: Thu, 14 Dec 2017 00:00:05 -0800

The document says:

 3. Replacement Recommendation

 If authentication is implemented, then AES-CMAC as
 specified in RFC 4493 [RFC4493] SHOULD be computed over
 all fields in the NTP header, and any extension fields
 that are present in the NTP packet as described in RFC
 5905 [RFC5905].  The MAC key for NTP SHOULD be 128 bits
 long AES-128 key and the resulting MAC tag SHOULD be 128
 bits long as stated in section 2.4 of RFC 4493 [RFC4493].
 NTP makes this transition possible as it supports algorithm
 agility as described in Section 2.1 of RFC 7696 [RFC7696].

The following are not defined in the document.  Should they be?

- MAC key
- MAC tag

Why was "SHOULD" used in the language above?  How would things behave if
any of the values above were not 128 bits long?

Should:

 The MAC key for NTP SHOULD be 128 bits
 long AES-128 key ...

be:

 The MAC key for NTP SHOULD be the 128 bit
 long AES-128 key ...

RFC4493 requires a 128 bit key.

Is it the intent of the authors that the only allowed key length will be
128 bits?

Users might not be that precise, and since these keys will likely be
used interactively for configuration purposes (manual configuration,
mode 6 passwords, sntp authentication, etc.) there is benefit to be had
by specifying how to extend a shorter key, or how to shorten a longer
key.  Anything other than clearly describing these processes in this
document will lead to difficult user acceptance and/or interoperability
problems.

I submit these issues must be properly addressed before advancing this
document.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!