Subject: Re: [Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 4 Jan 2019 11:23:53 -0500

Hi Benjamin,

Thanks for the comments.

On Mon, Nov 19, 2018 at 1:41 PM Benjamin Kaduk <[email-masked]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ntp-mac-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please consider using the RFC 8174 version of the BCP14 boilerplate.
>
> It's somewhat surprising to me that this document seems to focus on the
> "md5 is broken" aspect of the previous ntp-md5 construction, with no
> mention that there is additionally a cryptographic flaw: it is subject to
> length-extension attacks.  (I'm told that no practical attacks of this
> nature are known, but it still seems prudent to note the additional flaw in
> the mechanism being replaced.)
>
> Similarly, to avoid concerns about the risk of extension attacks with the
> new construction, it may be worth explicitly noting that the CMAC
> construction is secure even in the presence of variable length messages
> (see, e.g., [OMAC1a] from RFC 4493).  (In other contexts the message length
> is explicitly included as an input to the MAC, though given the above that
> does not seem necessary here.)
>
> Section 3
>
>    If authentication is implemented, then AES-CMAC as specified in RFC
>
> Maybe "NTP authentication"?
>

hmmm.. ok!

>
>    described in RFC 5905 [RFC5905].  The MAC key for NTP MUST be at
>    least 128 bits long AES-128 key and the resulting MAC tag MUST be at
>    least 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493].
>
> I'm not sure I understand why these are "at least" -- if AES-128 is used,
> exact matching should be fine.
>

I think it's fair to remove "at least" for the MAC key as you said that it
would exactly be 128 bits for AES-128. However, for the MAC tag I would
prefer to keep the "at least" part to be sure that the tag is not truncated
to less than128 bits. Does this make sense?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Jan 2019 09:21:29 -0800

> to less than128 bits. Does this make sense?

Well, the CMAC tag is 128 bits, so "at least 128 bits" == "128 bits".

-Ekr