1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
= Standards Conformance
include::include-html.ad[]
== Table of Contents
* link:#standards-overview[Overview of relevant standards]
* link:#against5905[Divergences from RFC 5905]
* link:#against2030[Divergences from RFC 2030]
[[standards-overview]]
== Overview of relevant standards
The principal standard informing the NTPsec software is
link:https://tools.ietf.org/html/rfc5905[RFC 5905: Network Time Protocol
Version 4: Protocol and Algorithms Specification].
SNTP is specified by link:https://tools.ietf.org/html/rfc2030[RFC 2030:
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI].
Extension fields are described by
link:https://tools.ietf.org/html/rfc7822[RFC 7822: Network Time Protocol
Version 4 (NTPv4) Extension Fields].
NTPsec has entirely dropped conformance with the Autokey feature
described in link:https://tools.ietf.org/html/rfc5906[RFC 5906]. Autokey
never quite worked, and the design was unstable enough that if there
was ever actually a time when it fully conformed to its RFC that span
must have been pretty short.
Older NTP RFCs such as link:https://tools.ietf.org/html/rfc1305[RFC 1305]
are no longer relevant.
link:https://tools.ietf.org/rfc/rfc5297.txt[RFC 5297] describes the
authenticated encryption used in Network Time Security
key exchanges.
Network Time Security does not yet have a final fully accepted
RFC. The NTPsec implementation is based on the
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-17[version 17 draft].
[[against5905]]
== Divergences from RFC 5905
Code conformance was never quite exact even before the NTPsec fork.
In this section we attempt to list divergences. This list is probably
not exhaustive.
Modes 5 (Broadcast) and 6 (Broadcast client) are no longer implemented
in NTPsec, as they were impossible to secure. Mode 1 (Symmetric
Active) is no longer implemented; such packets are treated as ordinary
client (mode 3) packets. Mode 2 (Symmetric Passive) is still distinct
from mode 3 but its only effect is on initial poll interval.
In figure 8 of section 7.3, 128 bits (16 octets, corresponding to an
MD5 or AES-CMAC digest) is not the only possible length for the MAC. This was
a pre-NTPsec change present in NTP Classic versions after 2010.
NTPsec conforms to the
link:https://datatracker.ietf.org/doc/draft-ietf-ntp-data-minimization/[NTP
Client Data Minimization] draft RFC, which changes the client-side
generation of some packet headers.
NTPsec also implements
link:https://tools.ietf.org/html/rfc8573[RFC 8573:
Message Authentication Code for the Network Time Protocol].
The table of reference identifiers in Figure 12 is largely obsolete
and somewhat incomplete relative to the code.
In the table of KISS codes (Figure 13), only RATE still exists and is
implemented in NTPsec; others proved unnecessary or (in the cases of
DENY and RSTR) outright dangerous. INIT and STEP are no longer KoD
types but persist as peer statuses that may be reported by
{ntpqman}/{ntpmonman}. NTPsec has additional codes DNS and NTS for
preparatory phases in association setup.
The continuing relevance of much of Appendix A is doubtful.
[[against2030]]
== Divergences from RFC 2030
In the packet-format illustration of section 4 (NTP Message Format)
128 is not the only possible bit length for a MAC. However, this
field is not shipped in SNTP operation, so the flaw is theoretical.
Some packet mode values are, as previously noted, no longer
implemented. Many External Reference Source types are obsolete.
Broadcast, multicast and anycast modes are no longer implemented.
'''''
include::includes/footer.adoc[]
|
