Subject: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 26 Aug 2020 14:29:00 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-mode-6-cmds-09: Discuss

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-mode-6-cmds/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There seems to be an internal inconsistency regarding the format of the
data payload: at the start of Section 4 we see that "When present, the
data field contains a list of identifiers or assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...  where
<<identifier>> is the ASCII name of a system or peer variable specified
in RFC 5905 and <<value>> is expressed as a decimal, hexadecimal or
string constant in the syntax of the C programming language", but later
on we see that the Read Status reply "contains a list of binary-coded
pairs <<association identifier>> <<status word>>, one for each currently
defined association.  The "binary-coded" (with, apparently, implicit
length) seems at odds with the ASCII key/value assignment pairs.

The description of the Configure(8) command as "The command data is
parsed and applied as if supplied in the daemon configuration file"
lacks any reference to what that format is or how one might know what
format the peer expects.  This does not seem sufficiently specified so
as to admit interoperable implementation.

The description of the Read MRU(10) command also seems underspecified.
What name=value pairs affect the selection of records (and how)?  Is
there a particular name used with name=value pair for the returned
nonce, or how is the returned nonce framed?  If it's
implementation-specific, say so.

The only currently specified authentication scheme for these commands
appears to be DES-CBC-MAC, from Appendix C of RFC 1305.  (RFC 5905
suggests that existing implementations, however, use a different
keyed-MD5 scheme that is similarly flawed.)  As a CBC-MAC, this
mechanism is subject to an extension attack, allowing an attacker to
observe an existing valid packet and construct a forged packet with
valid MAC by appending additional data at the end.  This, therefore,
fails to actually provide the key property of authentication.  There are
additional fundamental issues with the NTP authentication format
(independently of the DES-CBC-MAC scheme), which may not quite rise to
DISCUSS-level, and accordingly are listed in the COMMENT section.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Depending on how my discuss points are resolved, I may have to switch to
Abstain, as I cannot support publication of a document as status other
than historic that makes a normative reference to the obsolete RFC 1305
for the authenticator format/procedures.

In general, many of the descriptions for particlar codepoints are
single-word or single-line descriptions that do not provide enough
detail to give confidence of interoperable implementation; in some cases
("kernel loop discipline status changed") they are tied to particular
implementation strategies that are not universally applicable.

The considerations of BCP 201 with respect to algorithm agility appear
to be quite relevant, with the 96-bit authenticator format locking us
into at best 64 bits of MAC, which is fairly weak for Internet use, and
32 bits of key identifier.  This presents its own problems, as 32 bits
is too small for a value that is unilaterally assigned by many/all
participants and expected to be globally unique, but is rather large for
a key identifier space that is centrally managed for use within a single
administrative domain.  (The currently specified DES-CBC checksum from
RFC 1305 is, of course, considered insecure at this point, as with all
things single-DES.)

I see we defer to RFC 1305 for key management, which also defers the
matter as out of scope, but the considerations of BCP 107 seem to remain
relevant even in that case.

This document seems to be discussing a protocol over UDP that includes
its own fragmentation mechanism; would the UDP Usage Guidelines of RFC
8085 (BCP 145) not be applicable?

I see that there has been substantial previous discussion about this
document's intended status, with the change to Informational from
Historic occurring only recently.  The body text, however, still has
several references to "historical record" and other "historic" things
that don't seem quite right in an Informational document.  In light of
the protocol flaws mentioned in my Discuss section, my personal stance
is that Historic is the most appropriate status, though it would also be
reasonable to publish an Informational document on "the Network Time
Foundation's implementation of NTP mode 6 control commands".

Section 1.1

   Most control functions involve sending a command and receiving a
   response, perhaps involving several fragments.  The sender chooses a
   distinct, nonzero sequence number and sets the status field and "R"
   and "E" bits to zero.  [...]

It may be worth a reference to draft-gont-numeric-ids-sec-considerations
(I am AD-sponsoring this document) for the generation of these sequence
numbers, though maybe the actual definition of the field in Section 2 is
the better place from which to make such a reference.  (Also for the
Associate ID, it looks like.)

Section 3

I note that the order of word formats in the figure does not match the
subsection order.

Section 3.1

nit: the table entry for System Event Code 9 seems to be missing a word
("end"?).

   System Event Counter (Count): This is a four-bit integer indicating
   the number of system events occurring since the last time the System
   Event Code changed.  Upon reaching 15, subsequent events with the
   same code are not counted.

I get the impression from reading this (and similar text in subsequent
sections) that the "events" in question are exactly the behavior
specific to the event code in question, but it is hard to be sure when
it's left implicit.

Section 3.2

   A peer status word is returned in the status field of a response to a
   read status, read variables or write variables command and appears
   also in the list of association identifiers and status words returned
   by a read status command with a zero association identifier.  The

Given that this is the "Peer Status Word" section, shouldn't this be
"non-zero association identifier"?

   Peer Status (Status): This is a five-bit code indicating the status
   of the peer determined by the packet procedure, with bits assigned as
   follows:

We could probably spend a few more words saying that the bit being set
to 1 indicates the "true"/"yes" form of the meaning.

    |   6   | no reply (only used with one-shot ntpd -q)             |

It doesn't really seem appropriate to hardcode implementation details
("ntpd -q") here.

    |  13   | popcorn spike suppressed by peer clock filter register |

"popcorn spike" seems to appear only in the code skeleton of RFC 5905
and is not otherwise a defined term.  I do see a note in
draft-ietf-ntp-ntpv4-algorithms but we don't reference that document at
all; as such, this sems like jargon that's not appropriate for the
protocol spec.

Section 3.3

    |       0      | clock operating within nominals                  |

In the vein of my previous comment about "event" ambiguity, what event
would happen to cause the counter to increment while this is the clock
code?

Section 4

   Commands consist of the header and optional data field shown in
   Figure 2.  When present, the data field contains a list of

I think this is actually Figure 1.

   identifiers or assignments in the form
   <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...  where

Please clarify whether the comma is a literal comma as separator (or
what separator is used between key/value pairs), and also whether any
escaping might be needed if certain characters need to appear in the
<<value>> portion.

   language.  Where no ambiguity exists, the <169>sys.<170> or
   <169>peer.<170> prefixes can be suppressed.  Whitespace (ASCII

Are the <169>/<170> mangled charset conversion issues?  (I'm not sure
which charset, though!)  Also appears later around '.'.

   guidelines defined in [RFC5952].  Timestamps, including reference,
   originate, receive and transmit values, as well as the logical clock,
   are represented in units of seconds and fractions, preferably in
   hexadecimal notation.  Delay, offset, dispersion and distance values
   are represented in units of milliseconds and fractions, preferably in
   decimal notation.  All other values are represented as-is, preferably
   in decimal notation.

(side note) a bit surprising to see the mixed hex/decimal preference.

   Read Clock Variables (4): The command data field is empty or contains
   a list of identifiers separated by commas.  The association
   identifier selects the system clock variables or peer clock variables
   in the same way as in the Read Variables command.  The response
   includes the requested clock identifier and status word and the data
   field contains a list of clock variables and values, including the
   last timecode message received from the clock.

Where is the format of the "timecode message received from the clock"
specified?  Is it a binary or ASCII encoding?

Is there a list or registry for what the variables in question are?

   significant.  Implementations should include sanity timeouts which
   prevent trap transmissions if the monitoring program does not renew
   this information after a lengthy interval.

Can we give some more concrete guidance on what constitutes a "lengthy
interval"?  Days?

   Save Configuration (9): Write a snapshot of the current configuration
   to the file name supplied as the command data.  Further, the command
   is refused unless a directory in which to store the resulting files
   has been explicitly configured by the operator.

This file is still on the NTP server, right?

   Read ordered list (11): Retrieves an ordered list.  If the command
   data is empty or the seven characters "ifstats" the associated
   statistics, status and counters for each local address are returned.
   If the command data is the characters "addr_restrictions" then the
   set of IPv4 remote address restrictions followed by the set of IPv6
   remote address restrictions (access control lists) are returned.

This phrasing suggests that the command data is just the "name" part, not
a full "name=value" expression that was previously claimed to be the
format for the data section.

Section 6

I think it may be worth specifically calling out the trap mechanism as a
DoS vector as well as the generic "NTP control messages as DDoS vector"
discussion -- AFAICT spoofed UDP packets can register any number of
trap recipients and then a storm of outgoing packets can be prompted by
causing the trap condition.  (If there was only one registered trap
address/port active at any given time, this would be less of a concern,
but that doesn't seem to be the case.)

(There is also a related risk in terms of causing the NTP server to hold
all the state for so many trap registrations, but the state per address
seems relatively small.)

We should probably talk about the situation where a given message has
multiple name=value pairs for the same name, as security issues can
result when the parties disagree about which is to be used.  (Having
this rejected entirely as a protocol error is a fine option.)

There are probably some privacy considerations for some of the commands'
responses, e.g., the MRU gives information about who is using the
server, etc.

   However, this document argues that an NTP host must authenticate all
   control queries and not just ones that overwrite these variables.
   Alternatively, the host can use a whitelist to explicitly list IP
   addresses that are allowed to control query the clients.  These

What does "this document argues that" mean?  Is it a MUST-level
requirement?  (If so, then the text in the description of the Read
ordered list(11) command about "this opcode requires authentication" is
redundant and should be removed.)

Also, authentication does not inherently imply authorization; I think we
should say something about the server's authorization policy.

Also, we generally do not consider IP ACLs to be a security mechanism
(absent, e.g., IPsec), even if they can still have utility as a
front-line filtering option.

      *  In the client/server mode, the client stores its local time
         when it sends the query to the server in its xmt peer variable.
         This variable is used to perform TEST2 to non-cryptographically

What is TEST2/where is it documented?

   o  The mode 6 and 7 messages are vulnerable to replay attacks
      [CVE-Replay].  If an attacker observes mode 6/7 packets that
      modify the configuration of the server in any way, the attacker
      can apply the same change at any time later simply by sending the
      packets to the server again.  The use of the nonce (Request Nonce
      command) provides limited protection against replay attacks.

We seem to only document the usage of the Nonce for the Read MRU(10)
command, but the anti-replay functionality is generally useful.
Additional description of actual/intended nonce usage would be
beneficial.

   NTP best practices recommend configuring ntpd with the no-query
   parameter.  The no-query parameter blocks access to all remote

This is written in an implementation-specific manner and should be
rewritten to describe the protocol behavior -- "NTP best practices"
relate to the protocol, not the specific implementation.

   configuration of the hosts in certain scenarios.  Such hosts tend to
   use firewalls or other middleboxes to blacklist certain queries
   within the network.

There has been quite a bit of recent discussion on ietf@ relating to
terminology choices, as relates to "blacklist"/"whitelist" and other
terms.  I hope that the authors' usage of the term (both here and in
subsequent paragraphs) is an informed decision in light of those
community discussions.

Appendix A

   The format of the NTP Remote Facility Message header, which
   immediately follows the UDP header, is shown in Figure 3.  Following
   is a description of its fields.  Bit positions marked as zero are
   reserved and should always be transmitted as zero.

(I don't see any fields marked thusly; just the one "MBZ" field that has
its own description.)

   Implementation : The version number of the implementation that
   defined the request code used in this message.  An implementation
   number of 0 is used for a Request Code supported by all versions of
   the NTP daemon.  The value 255 is reserved for future extensions.

What is "the NTP daemon"?  A particular implementation?

   Data : A variable-sized field containing request/response data.  For
   requests and responses, the size in octets must be greater than or
   equal to the product of the number of data items (Count) and the size
   of a data item (Size).  For requests, the data area is exactly 40

I suggest saying more specifically which size it is that "must be
greater [...]".

---

From: Hal Murray <[email-masked]>
Date: Thu, 27 Aug 2020 02:00:34 -0700

Benjamin Kaduk  said:
> The considerations of BCP 201 with respect to algorithm agility appear to be
> quite relevant, with the 96-bit authenticator format locking us into at best
> 64 bits of MAC, which is fairly weak for Internet use, and 32 bits of key
> identifier.  This presents its own problems, as 32 bits is too small for a
> value that is unilaterally assigned by many/all participants and expected to
> be globally unique, but is rather large for a key identifier space that is
> centrally managed for use within a single administrative domain.  (The
> currently specified DES-CBC checksum from RFC 1305 is, of course, considered
> insecure at this point, as with all things single-DES.) 

We are down in the weeds, but ...

The 32 bit Key-ID is not globally unique.  With existing code, it's per 
server.  There is no reason that it couldn't be per client-server.  (That is 
unlikely to work if the client is using DHCP.)

An additional complication is that Autokey (RFC 5906) uses the top 16 bits so that leaves only 16 bits for manual assignment.

----------

Thanks for pointing out the 64 bit MAC.  I've been working in this area for a long time and don't remember seeing any 8 byte MACs.  It would be an interesting archeology project to figure out when support for MD5 (16 bytes) and SHA-1 (20 bytes) was added to the code.

RFC 8573 added AES-128 CMACs.

RFC 7822 describes the results of a lot of discussion about how to make old MACs coexist with extension fields.   My memory is that the discussion focused on 16 and 20 byte MACs as used by MD5 and SHA-1.  I think the wording in the RFC supports 20 or shorter.  I don't think any code supports 8 byte MACs.

In practice, in addition to agreeing on the Key and Key-ID, you also have to agree on the algorithm.  There is nothing in the packet that tells you which algorithm to use.  A while ago, you could make a good guess between MD5 and SHA-1 based on the length.  But now, AES-128 is also 16 bytes.  

-- 
These are my opinions.  I hate spam.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 27 Aug 2020 13:44:09 +0200

See my comments inline... 

>>> Benjamin Kaduk via Datatracker <[email-masked]> schrieb am 26.08.2020
um
23:29 in Nachricht <[email-masked]>:
> draft‑ietf‑ntp‑mode‑6‑cmds‑09: Discuss
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss‑criteria.html 
> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑mode‑6‑cmds/ 
> 
> 
> 
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> DISCUSS:
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> on we see that the Read Status reply "contains a list of binary‑coded
> defined association.  The "binary‑coded" (with, apparently, implicit

There a more minor issues:
First one could assume that all identifier-value pairs are in one long line,
but actually there are line breaks in the output.
The other thing is: I the value itself contains a comma, how is that encoded?
It could be that current implementations just don't use commas in values...

> as to admit interoperable implementation.

I agree.

> implementation‑specific, say so.
> 
> appears to be DES‑CBC‑MAC, from Appendix C of RFC 1305.  (RFC 5905
> keyed‑MD5 scheme that is similarly flawed.)  As a CBC‑MAC, this
> (independently of the DES‑CBC‑MAC scheme), which may not quite rise to
> DISCUSS‑level, and accordingly are listed in the COMMENT section.
> 
> 
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> COMMENT:
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> single‑word or single‑line descriptions that do not provide enough
> to be quite relevant, with the 96‑bit authenticator format locking us
> administrative domain.  (The currently specified DES‑CBC checksum from
> things single‑DES.)
> It may be worth a reference to draft‑gont‑numeric‑ids‑sec‑considerations
> (I am AD‑sponsoring this document) for the generation of these sequence
>    System Event Counter (Count): This is a four‑bit integer indicating

I was woindering on this as well. The implementation does that, but probably
it would make sense to incremewnt that number on every new event, so there's a
change 1 out of 16 to detect when new events have arrived since last polling.

> "non‑zero association identifier"?
> 
>    Peer Status (Status): This is a five‑bit code indicating the status
>     |   6   | no reply (only used with one‑shot ntpd ‑q)             |
> 
> ("ntpd ‑q") here.
> draft‑ietf‑ntp‑ntpv4‑algorithms but we don't reference that document at
>    decimal notation.  All other values are represented as‑is, preferably
>    in decimal notation.
> 

Naturally the format depends on the clock being used, e.g.:
timecode="\x0227.08.20; 4; 08:48:57;    S   \x03".
In the example binary characters are encoded as ASCII. I don't know if that
escape mechanism is specified anywhere.

> This file is still on the NTP server, right?

The file is written on the server, not on the client (if that was your
question).

> discussion ‑‑ AFAICT spoofed UDP packets can register any number of
> What does "this document argues that" mean?  Is it a MUST‑level
> front‑line filtering option.
> 
>          This variable is used to perform TEST2 to non‑cryptographically
> 
>       [CVE‑Replay].  If an attacker observes mode 6/7 packets that
> command, but the anti‑replay functionality is generally useful.
>    NTP best practices recommend configuring ntpd with the no‑query
>    parameter.  The no‑query parameter blocks access to all remote
> 
> This is written in an implementation‑specific manner and should be
> rewritten to describe the protocol behavior ‑‑ "NTP best practices"
>    Data : A variable‑sized field containing request/response data.  For
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Aug 2020 09:59:37 -0700

> An additional complication is that Autokey (RFC 5906) uses the top 16 bits so that leaves only 16 bits for manual assignment.

Thanks for the extra background on the Key-ID.

I would be quite happy if the spec here does not match existing
deployments!  But, we should make sure we are documenting what is actually
used, in that case.

> In practice, in addition to agreeing on the Key and Key-ID, you also have to agree on the algorithm.  There is nothing in the packet that tells you which algorithm to use.  A while ago, you could m…

General crypto best practice is to only use a given key for a single usage
and with a single algorithm, so my expectation is that the algorithm would
be assigned/negotiated at the same time that the key and key-ID are.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Aug 2020 10:01:54 -0700

> It could be that current implementations just don't use commas in values...

That's also a good point; I think I had meant to note it as well but failed
to do so (there is another document I was reviewing in parallel that has a
similar potential concern).

> escape mechanism is specified anywhere.

It's probably not interoperable if it's not specified somewhere...

> The file is written on the server, not on the client (if that was your

That was the question, yes.

Thanks,

Ben

---

From: Hal Murray <[email-masked]>
Date: Thu, 27 Aug 2020 11:08:05 -0700

[email-masked] said:
> and with a single algorithm, so my expectation is that the algorithm would be
> assigned/negotiated at the same time that the key and key-ID are. 

Correct.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 28 Aug 2020 08:30:49 +0200

>>> Benjamin Kaduk <[email-masked]> schrieb am 27.08.2020 um 18:59 in Nachricht
<[email-masked]>:

[...]
> be assigned/negotiated at the same time that the key and key‑ID are.

While many decisions in the past were made to keep up backwards compatibility,
the encryption type is set up indirectly vie the ntp.keys file. However (AFAIR)
the file is not part of the NTP specification, so for the on-wire protocol
there's no change to get the encryption type. One might guess, however.

Probably this was an omission after the only encryption type (DES) had been
extended to allow MD5 also (in NTPv3 AFAIR). The later on it was still
forgotten.

Looking up the specs I found

"   Key Identifier (keyid): 32-bit unsigned integer used by the client
   and server to designate a secret 128-bit MD5 key." (page 23)

"   Message Digest (digest): 128-bit MD5 hash computed over the key
   followed by the NTP packet header and extensions fields (but not the
   Key Identifier or Message Digest fields)." (page 23)

"   keyid: Symmetric key ID for the 128-bit MD5 key used to generate and
   verify the MAC.  The client and server or peer can use different
   values, but they must map to the same key." (page 32)

Actually I don't understand the part: "The client and server or peer can use
different
values, but they must map to the same key."

All the code in the spec just seems to care about MD5.

Regards,
Ulrich

> ‑Ben

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 28 Aug 2020 09:16:53 +0200

Hi!

See my slepping-corrections inline. Sorry for that. Too much work, too little
sleep...

>>> "Ulrich Windl" <[email-masked]> schrieb am 28.08.2020
um
08:30 in Nachricht <[email-masked]>:
> the encryption type is set up indirectly vie the ntp.keys file. However 
s/vie/via/

> (AFAIR)
s/change/chance/
> extended to allow MD5 also (in NTPv3 AFAIR). The later on it was still
s/The/Then/

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 28 Aug 2020 09:44:27 +0200

>>> Ulrich Windl <[email-masked]> schrieb am 28.08.2020 um 09:16
in Nachricht <5F48AF65.CB2 : 161 : 60728>:
> Hi!
> 
> See my slepping-corrections inline. Sorry for that. Too much work, too 
> little sleep...

Sorry for the SPAM, but I actually had intended to write "spelling corrections". The human brain is a remarkable device ;-)

---

From: Hal Murray <[email-masked]>
Date: Sat, 29 Aug 2020 01:46:26 -0700

[email-masked] said:
> While many decisions in the past were made to keep up backwards
> compatibility, the encryption type is set up indirectly vie the ntp.keys
> file. However (AFAIR) the file is not part of the NTP specification, so for
> the on-wire protocol there's no change to get the encryption type. One might
> guess, however.

> extended to allow MD5 also (in NTPv3 AFAIR). The later on it was still

No, it's not an omission.  There is no need for the encryption type to be on 
the wire.  The admins for the client and server agree on the type while they 
are agreeing on the key and keyid.

The backwards compatibility was just good luck.

> different values, but they must map to the same key." 

I think it's a bug.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 29 Aug 2020 02:47:49 -0700

> are agreeing on the key and keyid.

It's not an omission, and that the encryption type is not part of the
on-wire protocol is a clear feature.

> The backwards compatibility was just good luck.

I don't understand.  Backward compatibility?  Good luck?

The NTP MAC is the stuff after the base packet and any EFs.

It is comprised of a 32-bit (4 octet) keyid and a digest payload.

This digest payload can be a number of different sizes.  RFC5905 talks
about the size needed for an MD5 digest.  Other digests and other digest
sizes are perfectly acceptable.

>> different values, but they must map to the same key." 

I don't know anybody who is using one keyid for authenticating from A to
B, and a different keyid for authenticating from B to A.  But there's no
reason that should not be permitted.  I don't even believe there should
be a requirement that this case MUST map to the same key.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 31 Aug 2020 10:58:49 +0200

>>> Hal Murray <[email-masked]> schrieb am 29.08.2020 um 10:46 in
Nachricht <[email-masked]>:

> [email-masked]‑regensburg.de said:
>> the on‑wire protocol there's no change to get the encryption type. One
might

> are agreeing on the key and keyid.

Well, if there's only one algorithm, you don't need to specify it, but if
there are multiple, it would be quite helpful. It's not needed, maynbe, but the
code tried to guess from the packet sizes what type of algorithm it might be.
DES vs. MD5 vs. SHA-a may be easy, but the more algorithms are allowed, the
trickier it becomes...

Original comment from NTP source:
        /*
         * Parse the extension field if present. We figure out whether
         * an extension field is present by measuring the MAC size. If
         * the number of words following the packet header is 0, no MAC
         * is present and the packet is not authenticated. If 1, the
         * packet is a crypto-NAK; if 3, the packet is authenticated
         * with DES; if 5, the packet is authenticated with MD5; if 6,
         * the packet is authenticated with SHA. If 2 or * 4, the packet
         * is a runt and discarded forthwith. If greater than 6, an
         * extension field is present, so we subtract the length of the
         * field and go around again.
         */

> ‑‑

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 31 Aug 2020 11:21:20 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.08.2020 um 11:47 in Nachricht
> be a requirement that this case MUST map to the same key.

However as not even the reference implementation supports it (AFAIK) (and I guess nobody else), so why make that statement.
Are you saying for "server server1 key 123" server1 is receiving queries authenticated with key 123, but is allowed to send replies using any different key, and that response is OK? That would mean if one key is disclosed, an attacker could send bogus responses using that key, right?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Aug 2020 02:35:37 -0700

Ulrich,

>          * field and go around again.

You're looking at a comment that was written a very long time ago, back
when there were very few algorithms.  At the time it was written, it
described the status quo.

Think of it as describing the "tail", not the "dog".  If that make sense
outside of English.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Aug 2020 02:43:52 -0700

> Are you saying for "server server1 key 123" server1 is receiving queries authenticated with key 123, but is allowed to send replies using any different key, and that response is OK? That would mean…

I'm not saying anything about it, because that would be taking a stand
on behavior outside the scope of an informational specification.

You and I seem to be the minority of people who believe this document
should be a full-on Standards document that tackles these issues, however.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2020 12:24:53 +0200

> Are you saying for "server server1 key 123" server1 is receiving queries authenticated with key 123, but is allowed to send replies using any different key, and that response is OK? That would mean…

Yes, that is a security issue if an NTP client accepts responses
authenticated with a key that it uses to authenticate responses to its
own clients as the clients can perform a MITM attack on the server.
IIRC with the ntp.org implementation you need to specify IP addresses
in the key file to enforce that, which might be difficult to do if the
clients are allowed the change their address. Other implementations
require the responses to be authenticated with the key specified on
the "server" line and I think that should be recommended in the NTP
specification.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Aug 2020 04:16:29 -0700

> the "server" line and I think that should be recommended in the NTP

I certainly wasn't suggesting anything like that.

I was simply trying to point out that A->B could use any arbitrary keyID
to authenticate those packets, as long as A and B agreed on the keyID,
algorithm, and key, and B->A could also use an arbitrary keyID,
algorithm, and key as long as there was an agreement on that.

I'm not aware of anybody who is doing this now.

There are other possibilities as well.

But this is beyond the scope of the mode 6 documents.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2020 13:32:10 +0200

> algorithm, and key as long as there was an agreement on that.

Yes, I agree it's possible, but there doesn't seem to be a good reason
to do that. The additional configuration required to keep it secure is
impractical.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Aug 2020 04:52:36 -0700

On 8/31/2020 4:32 AM, Miroslav Lichvar wrote:
> to do that.

Likely true.  But even so, a good reason could present itself an I don't
see any compelling reason we should proactively limit this possibility.

> The additional configuration required to keep it secure is
> impractical.

Really?  I can see how to do a straightforward implementation of this in
the Reference Implementation.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2020 14:24:32 +0200

> see any compelling reason we should proactively limit this possibility.

A strong reason for not allowing responses authenticated with other
keys is avoiding insecure configurations. We have discussed this
before. I'd say most users that have enabled multiple symmetric keys
in ntpd don't know they need to be limited to IP addresses to prevent
the MITM attacks.

> the Reference Implementation.

Why is it not implemented?

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Mon, 31 Aug 2020 15:52:43 -0700

>          * field and go around again.

I think that comment is out of date.

ntpsec gets the algorithm from the keys file.  I am less familiar with the 
reference implementation, but I'm pretty sure it does the same.

If nothing else, the above comment won't work with AES, RFC-8573, which is the 
same length as MD5.