Message Authentication Code for the Network Time Protocol
RFC 8573

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana No Objection

Comment (2018-11-19 for -05)
From §3:
   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].

When would AES-CMAC not be computer over all fields, or when would it not be used?  IOW, why is a MUST not used?  The text already indicates that it is talking about "if authentication is implemented..."

Benjamin Kaduk No Objection

Comment (2018-11-19 for -05)
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"?

   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.

Martin Vigoureux No Objection

Comment (2018-11-21 for -05)
No email
send info
Just a nit:

s/succesfully/successfully/

Warren Kumari No Objection

Comment (2018-11-19 for -05)
It would be useful to know if this is actually implemented / deployed. I spent some time looking around, and found something saying that this was slated for ntp-4.4.0, but it looks like ntp-4.2.8p12 was just recently released? There was some mumbling about new numbering formats, but I didn't explore that rabbithole. 
https://github.com/ntp-project/ntp/blob/stable/ntpd/ntp.conf.html has refernces to MD-5, but not AES, so, um, perhaps it isn't?

(Suresh Krishnan; former steering group member) Yes

Yes ( for -05)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection (2018-11-19 for -05)
Thanks to everyone who worked on this document.

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.

I also have a handful of minor and editorial comments that you may want to
consider addressing.

---------------------------------------------------------------------------

Please consider addressing these id-nits issues:

  ** The abstract seems to contain references ([RFC5905], [RFC4493]), which
     it shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  -- The draft header indicates that this document updates RFC5905, but the
     abstract doesn't seem to directly say this.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please update to use the boilerplate in RFC 8174.

---------------------------------------------------------------------------

§3:

>  A symmetric key is a triplet of ID,
>  type (e.g.  MD5, AES-CMAC) and the key itself.

I don't follow this. A naïve reading of this sentence would lead me to believe
that the key contains three fields, one of which is itself.  I suspect you're
using "key" here to refer to two somewhat different constructs.  Consider
giving them more unique names.

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-11-19 for -05)
Section 4: It seems like Intel's New Instruction Set either needs a citation or needs to be removed as a specific example unless it's expected to continue to be a meaningful example for as long as this document remains in force.

Section 6: "NIST document" seems like it should have a more descriptive title

Section 9.1: The link to the NIST document is broken.

(Ben Campbell; former steering group member) No Objection

No Objection (2018-11-20 for -05)
§2: "is not a secure MAC and therefore MUST be
deprecated."

That "MUST" seems like a statement of fact rather than a normative requirement.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2018-11-17 for -05)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3591



COMMENTS
S 3.
>      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 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].

Is there a way for either of these values to be > 128 bits? If not,
maube just say "must be 128 buts:

(Ignas Bagdonas; former steering group member) No Objection

No Objection (2018-11-19 for -05)
What is the implementation status of this, and is there any deployment experience?

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2018-10-30 for -05)
I guess the assumption is that all hosts configured to use the same authentication scheme? Or would makse sense to add a short note on backward compatibility?

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -05)
No email
send info