Message Authentication Code for the Network Time Protocol
draft-ietf-ntp-mac-06
Yes
(Suresh Krishnan)
No Objection
(Alexey Melnikov)
(Deborah Brungard)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Warren Kumari
No Objection
Comment
(2018-11-19 for -05)
Sent
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 IESG member
Yes
Yes
(for -05)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-11-19 for -05)
Sent
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 IESG member
No Objection
No Objection
(for -05)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-11-19 for -05)
Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection
(2018-11-19 for -05)
Sent
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..."
Ben Campbell Former IESG member
No Objection
No Objection
(2018-11-20 for -05)
Sent
§2: "is not a secure MAC and therefore MUST be deprecated." That "MUST" seems like a statement of fact rather than a normative requirement.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-11-19 for -05)
Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -05)
Not sent
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-11-17 for -05)
Sent
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 IESG member
No Objection
No Objection
(2018-11-19 for -05)
Sent
What is the implementation status of this, and is there any deployment experience?
Martin Vigoureux Former IESG member
No Objection
No Objection
(2018-11-21 for -05)
Not sent
Just a nit: s/succesfully/successfully/
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-10-30 for -05)
Sent
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 IESG member
No Objection
No Objection
(for -05)
Not sent
Terry Manderson Former IESG member
No Objection
No Objection
(for -05)
Not sent