[Git][NTPsec/ntpsec][master] 5 commits: drop/revise
Eric S. Raymond
gitlab at mg.gitlab.com
Mon Feb 4 02:31:58 UTC 2019
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
834b49fd by James Browning at 2019-02-04T02:28:07Z
drop/revise
- - - - -
de63b41c by James Browning at 2019-02-04T02:28:07Z
mode 7 next
- - - - -
8ff83678 by James Browning at 2019-02-04T02:28:07Z
Grammar
- - - - -
0a0ec9c8 by James Browning at 2019-02-04T02:28:07Z
comment grammar
- - - - -
8990804d by James Browning at 2019-02-04T02:28:07Z
strip header trailers
- - - - -
13 changed files:
- devel/nts.adoc
- docs/includes/auth-commands.adoc
- docs/includes/ntp-conf-body.adoc
- include/ntp_tty.h
- libntp/timespecops.c
- libparse/clk_sel240x.c
- ntpd/ntp_io.c
- ntpd/ntp_leapsec.c
- ntpd/ntp_refclock.c
- ntpd/refclock_generic.c
- tests/libntp/lfpfunc.c
- tests/libntp/timespecops.c
- tests/ntpd/leapsec.c
Changes:
=====================================
devel/nts.adoc
=====================================
@@ -9,7 +9,7 @@ The NTS implementation shall:
* Address RFC5705 Keying Material Exporting and AES_SIV (RFC5297) code
support which may not be natively supported in OpenSSL.
-* Comply with the standardized specification of
+* Comply with the standardized specification of
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp[NTS]
* Be interoperable with the other reference implementations in IETF hackathons.
@@ -25,18 +25,18 @@ NTP server with each request.
A cookie contains the AEAD algorithm and keys necessary to
authenticate a request. They are encrypted with the NTP servers
key. The NTP server decrypts the cookie to retrieve the
-the encryption parameters (AEAD algorithm and keys) and then uses
-then to authenticate the packet. To issue a new cookie, the NTP
+encryption parameters (AEAD algorithm and keys) and then uses
+them to authenticate the packet. To issue a new cookie, the NTP
server makes a new nonce and uses the AEAD algorithm and keys
from the old cookie.
NTS should avoid exposing information that would be useful in
tracking the client. (Consider a laptop that moves from home
-to work to a coffee shop.) Thus cookies should only used once.
+to work to a coffee shop.) Thus cookies should only be used once.
To implement that, each NTP response includes a new cookie, which is
encrypted when sent to the client. (Otherwise, the cookie could be
observed in transit, which would allow for tracking the client when
-it later echos that cookie back to the server.)
+it later echoes that cookie back to the server.)
NTS should not assist DDoS amplification. All NTP responses
are the same length as the request. This means that some
@@ -70,7 +70,7 @@ Charlies, e.g. in a data-center deployment or for load sharing.
\-------------------/
----
-In this diagram, an arrow means "initiates requests to".
+In this diagram, an arrow means "initiates requests to".
Responses flow in the other direction. Each connection
is used for one request/response transaction.
@@ -78,7 +78,7 @@ is used for one request/response transaction.
The NTS-KE server has to make cookies that the NTP server
will process. There are 2 ways to do that. First, they can share
the same key, new-cookie recipe, and new-key recipe. If they are
-in separate systems, the admin must setup the initial key and keep
+in separate systems, the admin must set up the initial key and keep
the keys in sync if either system gets trashed. The second way is
for the NTS-KE server to ask the NTP server for new cookies. If it
does that, it doesn't need to know the key or anything about the
@@ -87,11 +87,11 @@ contents of a cookie.
=== Alpha -> Bravo
NTP client to NTS-KE client (Alpha to Bravo) is pretty simple.
-As these will both be inside ntpd, this will be function calling,
+As these will both be inside ntpd, this will be function calls,
not a network connection.
==== NTS-KE client sends:
-- Host name of NTS-KE server
+- Hostname of NTS-KE server
- Optional preferred NTPD server hostname or IP Address
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.7[4.1.7]
- A sorted list of AEAD algorithms
@@ -130,7 +130,7 @@ Additionally, the NTP client SHOULD NOT initiate NTS for pool
associations by default. The most common pool is the public pool at
pool.ntp.org. The volunteer NTP servers will never be able to pass a
certificate check for <anything>.pool.ntp.org, so NTS-KE will always
-fail, and represents useless load on the public pool servers. As the
+fail, and represents a useless load on the public pool servers. As the
pool statement can be used in other configurations that could work
with NTS-KE, the NTP client SHOULD allow NTS to be enabled on pool
associations.
@@ -161,8 +161,8 @@ specified in the NTS draft.
The NTS-KE client (Bravo) and NTS-KE server (Delta) independently
derive the C2S and S2C keys. For OpenSSL, this is implemented by
making two calls to SSL_export_keying_material(), which implements
-RFC5705. The label and context inputs are provided in
-link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.1[5.1].
+RFC5705. The label and context inputs are provided in
+link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.1[5.1].
This process is deterministic, so both ends generate the same C2S and S2C.
The NTS-KE client passes C2S and S2C to the NTP client. The NTS-KE
@@ -184,21 +184,21 @@ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.3[5.
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.4[5.4]
- Authentication using C2S
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.6[5.6]
-
+
It gets back the same, with the cookie replaced with a new cookie
and S2C used for authentication and to encrypt the new cookie.
-The response is the same lengh.
+The response is the same length.
All the extra data is in real NTP extensions. (No more of
the magic length kludgery for the current shared key authentication.)
If packets (and hence cookies) are lost, the client will include
-a cookie-placeholder for each extra cookie it wants.
-link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.5[5.5]
+a cookie-placeholder for each extra cookie it wants.
+link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.5[5.5]
Those slots will be returned with new cookies.
-The AEAD algorithm used for authentication is setup to encrypt some
+The AEAD algorithm used for authentication is set up to encrypt some
data as well. For the request, the encrypted data is empty. For the
response, it contains a new cookie (or cookies). AEAD also needs a nonce.
@@ -310,7 +310,7 @@ TLSProtocol [+TLS1.2] [+TLS1.3]
Configures one or more sources for seeding the Pseudo Random Number
Generator (PRNG) in OpenSSL at startup time. One source per directive.
-Multiple directives may be used. Souce may be: builtin, "file:/dev/random",
+Multiple directives may be used. Source may be: builtin, "file:/dev/random",
"file:/dev/urandom", etc.
....
@@ -318,10 +318,10 @@ TLSRandomSeed source [bytes]
....
Sets the Certificate verification level for the Client Authentication.
-Level may be: none: no client Certificate is required at all, optional:
+The level may be: none: no client Certificate is required at all, optional:
the client may present a valid Certificate, require: the client has to
present a valid Certificate, optional_no_ca: the client may present a
-valid Certificate but it need not to be verifiable.
+valid Certificate but it need not be verifiable.
....
TLSVerifyClient level
@@ -360,7 +360,7 @@ keys.
When sending an NTP packet, the client attaches a cookie blob in
cleartext, then authenticates the packet using the C2S key. When
the NTP server receives the packet, it decrypts the cookie using its
-NTS Master Key to revover C2S and S2C. It uses C2S to authenticate the
+NTS Master Key to recover C2S and S2C. It uses C2S to authenticate the
packet. For the response, S2C is used to encrypt the new cookies and
authenticate the return packet.
@@ -368,11 +368,11 @@ authenticate the return packet.
How many cookies should the NTP client try to hold? 8
-There is no hard reason, but it is what the NTS-KE server SHOULD return.
+There is no hard reason, but it is what the NTS-KE server SHOULD return.
link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.6[4.1.6]
It also matches the number of samples that ntpd remembers (the reach bit
mask in ntpq/peers) and running out of responses is a good time to do
-special things like get a new pool server or get new cookies by running
+special things like getting a new pool server or getting new cookies by running
NTS-KE again.
---
@@ -388,12 +388,40 @@ Both connections contain C2S and S2C keys.
== Potential cookie recipe(s)
-. Form a plaintext according to cookie variation
-.. the AEAD algorthm number, and c2s/s2c keys.
-.. a countdown word, the AEAD algorthm number, and c2s/s2c keys.
-.. a countdown word, client IPv6 address, the AEAD algorthm number, and c2s/s2c keys.
-. encrypt it with the master key (which has nothing to do w/ TLS)
-. form the cookie w/ cookie recipe number, master key number, a nonce and the ciphertext.
+. Form a plaintext "P" comprised of records
+.. minimum of an AEAD algorithm record, c2s, and s2c key records
+.. (optional) previously connected network address (for academic purposes)
+.. (optional) a timestamp when to stop honoring the current cookie series
+.. (optional) a timestamp when the current cookie series began (for expiration)
+.. (optional) a Modified Julian Date when to stop honoring the current cookie series
+.. (optional) a MJD when the current cookie series began (for expiration)
+.. (optional) a number of cookies remaining before series expiration.
+.. (optional) the number of cookies (estimated) since series began for expiration.
+. encrypt it with the master key "K" (which has nothing to do w/ TLS)
+. form the cookie w/ records for the master key number "I", an unsized nonce "N", and the ciphertext "C".
+
+----
+base 29 NThkZGExNTYxZGY3YWQzMTkxOGI4OTQ0ZWQ5YTU3MTc= ZGZmZTg0MTBhZjk2YTgxOGE2ZDMwOGQ0Nzg0ZGMxNzg
+track 192.168.1.107
+btai 3753708891
+etai 3761747291
+bmjd 58460
+emjd 58557
+cdown 3460
+cup 4210
+----
+
+An overly complicated example plaintext. records are carriage return terminated and fields are horizontal tab separated.
+The example is set in January of 2019 for a chain starting mid-December and ending mid-March.
+It is likely that only one of the expiry fields is desirable.
+The cookie count up/down counter should change by the number of cookies issued (8).
+The c2s/s2c fields should be base64 encoded.
+
+----
+27391 MjI4MGVlYWY2ZWMzOGZjNmQ4MmFjMjhmMGViYzYxZTQ= U2FsdGVkX1/dO8WX4e+daOzR2dcRvbHOUv3jAMT51NttWrK+CnBUDWuhm54Hz31TG1P+VkWlrMGHAIHea9gQ3+shZj+I8pdPLrEn9V/E+1VJMC96qBo+x55yQmOyRLEJJSJMs25dSQ0idndKAOYqUOyulwruTe7QuPr+L5fVB9qSw2n18w/6BtnXsivAEjMpfxP9X7ZDZ46LHm1ayAcmMoccdjuwKqgPaa2ez33rlruXmcsF5omlguBZWxjm/iNZ
+----
+
+A wholly made up example cookie.
== Unresolved issues for the next RFC WG
@@ -403,13 +431,135 @@ The binary KE request-response format is unfortunate for all the usual
reasons (endianness issues etc). At the expected transaction volume,
the encode/decode overhead shouldn't be an issue.
-== Ridiculous questions
+== NTS/mode 7 next
+
+=== NTS and mode 6 and 7
+
+Network Time Security explicitly only supports modes 3 and 4 at this time.
+I see no reason why NTS could not be expanded to cover modes 1, 2, 6, and 7.
+Expansion to cover modes 6&7 should require an authentication token extension.
+
+
+=== mode 6 -> mode 7 next
+
+I feel that in keeping with comments. It should be possible to shift a copy of mode 6 to UTF-8 JSON-RPC and rebadge it as a new mode 7.
+The following is an overly verbose partial mockup of a transaction chain querying peer-stats.
+All the numbers should be in _decimal_ without the hexadecimal timestamps and such.
+
+[source, json]
+----
+{
+ "jsonrpc" : "2.0",
+ "id" : 1,
+ "params" : {},
+ "method" : "readstat"
+}
+{
+ "jsonrpc" : "2.0",
+ "id" : 1,
+ "result" : {
+ "answer" : {
+ "associations" : [
+ 62414,
+ 62413,
+ 62408,
+ 62407,
+ 62406,
+ 62405,
+ 62402,
+ 62401,
+ 62400,
+ 62399,
+ 62398
+ ]
+ }
+ }
+}
+
+{
+ "jsonrpc" : "2.0",
+ "id" : 2,
+ "params" : {
+ "association" : 62398
+ },
+ "method" : "readvar"
+}
+{
+ "jsonrpc" : "2.0",
+ "id" : 2,
+ "result" : {
+ "answer" : {
+ "hmode" : 3,
+ "filtdisp" : [
+ 14.68,
+ 1.5,
+ 2.36,
+ 3.45,
+ 4.75,
+ 5.19,
+ 6.19,
+ 7.12
+ ],
+ "keyid" : 0,
+ "dstadr" : "127.0.0.1",
+ "jitter" : 2.792031,
+ "dstport" : 123,
+ "rootdelay" : 0,
+ "dispersion" : 8.528601,
+ "flash" : 0,
+ "filtoffset" : [
+ -829.24,
+ -831.68,
+ -833.19,
+ -832.72,
+ -832.48,
+ -831.32,
+ -831.14,
+ -830.83
+ ],
+ "reach" : 255,
+ "mode" : 2,
+ "rootdisp" : 0,
+ "ppoll" : 6,
+ "reftime" : 3757323811.47605,
+ "delay" : 0,
+ "offset" : -829.240892,
+ "pmode" : 4,
+ "srcadr" : "127.127.46.0",
+ "precision" : -8,
+ "headway" : 0,
+ "hpoll" : 6,
+ "rec" : 3757323811.5776,
+ "xmt" : 3757323811.57759,
+ "stratum" : 0,
+ "srchost" : "GPSD(0)",
+ "unreach" : 0,
+ "srcport" : 123,
+ "leap" : 0,
+ "refid" : "GPSD",
+ "filtdelay" : [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0
+ ]
+ },
+ "association" : 62398
+ }
+}
+
+
+...
+----
+
=== link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.3[4.1.3], link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.4[4.1.4]
-Is the response in case of abuse 'continue abuse, just wait a minute'?
-=== link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.4[5.4], link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.5[5.5]
-When sending a cookie placeholder, are multiple cookie extensions sent?
+Is the response in case of abuse 'continue the abuse, just wait a minute'?
=== link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.7[5.7]
Does the unique identifier extension need to be omniversally unique?
=====================================
docs/includes/auth-commands.adoc
=====================================
@@ -69,10 +69,10 @@ The following options of the +server+ command configure NTS.
+ask+ _address_::
Use Network Time Security for authentication and encryption. Ask
for a specific NTS server, which may differ from the NTP server.
- Conforms to RFC3896 section 3.2.2 prescription for the Host part of
- a URI: that is, the +address_ may be a hostname, a FQDN, an IPv4
- numeric address, an IPv6 numeric address (in square brackets).
- Address may have the suffix +:port+ to specify a UDP port.
+ Conforms to RFC 3896 section 3.2.2 prescription for the Host part of
+ a URI: that is, the _address_ may be a hostname, an FQDN, an IPv4
+ numeric address, or an IPv6 numeric address (in square brackets).
+ The address may have the suffix +:port+ to specify a UDP port.
+require+ _address_::
Use Network Time Security for authentication and encryption.
=====================================
docs/includes/ntp-conf-body.adoc
=====================================
@@ -54,7 +54,7 @@ commands.
Following is a description of the configuration commands in
NTPv4. There are two classes of commands, association commands that
configure a persistent association with a remote server or peer or
-reference clock, and auxiliary commands that specify environmental
+reference clock, and auxiliary commands that specify environment
variables that control various related operations.
=== Association Commands ===
@@ -123,7 +123,7 @@ cracker.
Clients can be denied service because they are explicitly included in
the restrict list created by the restrict command or implicitly as the
result of cryptographic or rate limit violations. Cryptographic
-violations include certificate or identity verification failure; rate
+violations include certificate or identity verification failures; rate
limit violations generally result from defective NTP implementations
that send packets at abusive rates. Some violations cause denied service
only for the offending packet, others cause denied service for a timed
=====================================
include/ntp_tty.h
=====================================
@@ -21,7 +21,7 @@
*/
#define LDISC_STD 0x000 /* standard */
#define LDISC_RAW 0x020 /* raw binary */
-#define LDISC_7O1 0x100 /* 7-bit, odd parity for Z3801A */
+#define LDISC_7O1 0x100 /* 7-bit odd parity for Z3801A */
#define LDISC_REMOTE 0x080 /* remote mode */
#endif /* GUARD_NTP_TTY_H */
=====================================
libntp/timespecops.c
=====================================
@@ -19,7 +19,7 @@
* nanoseconds of a timespec are signed values. IMHO, the easiest way is
* to use a complement representation where the nanoseconds are still
* normalised, no matter what the sign of the seconds value. This makes
- * normalisation easier, since the sign of the integer part is
+ * normalization easier, since the sign of the integer part is
* irrelevant, and it removes several sign decision cases during the
* calculations.
*
@@ -28,7 +28,7 @@
* normalised result.
*
* The exception to this are functions fix a '_fast' suffix, which do no
- * normalisation on input data and therefore expect the input data to be
+ * normalization on input data and therefore expect the input data to be
* normalised.
*
* Input and output operands may overlap; all input is consumed before
@@ -72,7 +72,7 @@ normalize_tspec(
}
#else
/* since 10**9 is close to 2**32, we don't divide but do a
- * normalisation in a loop; this takes 3 steps max, and should
+ * normalization in a loop; this takes 3 steps max, and should
* outperform a division even if the mul-by-inverse trick is
* employed. */
if (x.tv_nsec < 0)
=====================================
libparse/clk_sel240x.c
=====================================
@@ -38,7 +38,7 @@
// character and end it when we see the \n.
//
// The q or quality character indicates satellite lock and sync. For the
-// purposes of NTP we are going to call it valid when we receive anything but
+// purposes of NTP, we are going to call it valid when we receive anything but
// a '?'. But we are only going to call it synced when we receive a ' '
//////////////////////////////////////////////////////////////////////////////
=====================================
ntpd/ntp_io.c
=====================================
@@ -2968,7 +2968,7 @@ process_routing_msgs(struct asyncio_reader *reader)
if (disable_dynamic_updates) {
/*
- * discard ourselves if we are not needed any more
+ * discard ourselves if we are not needed anymore
* usually happens when running unprivileged
*/
remove_asyncio_reader(reader);
=====================================
ntpd/ntp_leapsec.c
=====================================
@@ -902,7 +902,7 @@ do_hash_data(
EVP_MD_CTX * mdctx,
char const * cp )
{
- unsigned char text[32]; // must be power of two!
+ unsigned char text[32]; // must be a power of two!
unsigned int tlen = 0;
unsigned char ch;
=====================================
ntpd/ntp_refclock.c
=====================================
@@ -764,7 +764,7 @@ refclock_setup(
ttyp->c_oflag = 0;
ttyp->c_cflag = CS8 | CLOCAL | CREAD;
if (lflags & LDISC_7O1) {
- /* HP Z3801A needs 7-bit, odd parity */
+ /* HP Z3801A needs 7-bit odd parity */
ttyp->c_cflag = CS7 | PARENB | PARODD | CLOCAL | CREAD;
}
cfsetispeed(&ttyb, speed);
=====================================
ntpd/refclock_generic.c
=====================================
@@ -1891,7 +1891,7 @@ local_input(
{ /* simulate receive */
// FIXME - this copy is no longer needed
// This code is the result of a simple fix for SINGLEBUFFER
-// The copy used to go to add_full_recv_buffer, but that's not needed any more
+// The copy used to go to add_full_recv_buffer, but that's not needed anymore
// I'm not sure the local_receive below is correct
// Hal, 2018-Sep-21
buf = get_free_recv_buffer();
=====================================
tests/libntp/lfpfunc.c
=====================================
@@ -66,7 +66,7 @@ static int l_fp_ucmp(const l_fp first, l_fp second)
}
//----------------------------------------------------------------------
-// imlementation of the LFP stuff
+// implementation of the LFP stuff
// This should be easy enough...
//----------------------------------------------------------------------
@@ -144,7 +144,7 @@ static const size_t addsub_tot = (sizeof(addsub_tab)/sizeof(addsub_tab[0][0]));
// * The 'l_fp' fixed point fraction has 32 bits precision, so we allow
// for the LSB to toggle by clamping the epsilon to be at least 2^(-31)
//
-// * The double mantissa has a precsion 54 bits, so the other minimum is
+// * The double mantissa has a precision 54 bits, so the other minimum is
// dval * (2^(-53))
//
// The maximum of those two boundaries is used for the check.
=====================================
tests/libntp/timespecops.c
=====================================
@@ -153,7 +153,7 @@ TEST(timespecops, Helpers1) {
}
//----------------------------------------------------------------------
-// test normalisation
+// test normalization
//----------------------------------------------------------------------
TEST(timespecops, Normalise) {
@@ -558,7 +558,7 @@ TEST(timespecops, test_ToLFPabs) {
TEST(timespecops, test_FromLFPbittest) {
struct timespec limit = timespec_init(0, 2);
- // Not *exactly* a bittest, because 2**32 tests would take a
+ // Not *exactly* a bit test, because 2**32 tests would take a
// really long time even on very fast machines! So we do test
// every 1000 fractional units.
uint32_t tsf;
@@ -631,13 +631,13 @@ TEST(timespecops, test_LFProundtrip) {
}
//----------------------------------------------------------------------
-// conversion from l_fp, unsigned
+// conversion from l_fp unsigned
//----------------------------------------------------------------------
TEST(timespecops, test_FromLFPuBittest) {
struct timespec limit = timespec_init(0, 2);
- // Not *exactly* a bittest, because 2**32 tests would take a
+ // Not *exactly* a bit test, because 2**32 tests would take a
// really long time even on very fast machines! So we do test
// every 1000 fractional units.
uint32_t tsf;
=====================================
tests/ntpd/leapsec.c
=====================================
@@ -444,7 +444,7 @@ my_fprintf(FILE *stream, const char *fmt, ...) {
// ----------------------------------------------------------------------
-// test query in pristine state (bug#2745 misbehaviour)
+// test query in pristine state (bug#2745 misbehavior)
TEST(leapsec, lsQueryPristineState) {
int rc;
leap_result_t qr;
@@ -943,7 +943,7 @@ TEST(leapsec, ls2012seqInsDumb) {
TEST_ASSERT_EQUAL(0, qr.warped );
TEST_ASSERT_EQUAL(LSPROX_ALERT, qr.proximity);
- // NOW the insert/backwarp must happen
+ // NOW the insert/delete must happen
rc = leapsec_query(&qr, lsec2012+1);
TEST_ASSERT_TRUE(rc);
TEST_ASSERT_EQUAL(-1, qr.warped );
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/797de69d0b47474337f25a8184cda0b8539887c0...8990804d647389c7609448452f0fe547f6fb5887
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/797de69d0b47474337f25a8184cda0b8539887c0...8990804d647389c7609448452f0fe547f6fb5887
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190204/5b6b3951/attachment-0001.html>
More information about the vc
mailing list