[Git][NTPsec/ntpsec][master] 5 commits: formatting
Eric S. Raymond
gitlab at mg.gitlab.com
Mon Jan 21 11:33:15 UTC 2019
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
f65cfeee by James Browning at 2019-01-21T11:30:01Z
formatting
- - - - -
df209c72 by James Browning at 2019-01-21T11:30:01Z
diagram revision
- - - - -
d6c52110 by James Browning at 2019-01-21T11:30:01Z
ultralinking
- - - - -
f4cc2675 by James Browning at 2019-01-21T11:30:01Z
cookie dough
- - - - -
eef75902 by James Browning at 2019-01-21T11:30:01Z
question specs
- - - - -
1 changed file:
- devel/nts.adoc
Changes:
=====================================
devel/nts.adoc
=====================================
@@ -9,8 +9,8 @@ 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 NTS
- https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp
+* 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.
@@ -52,22 +52,22 @@ Charlies, e.g. in a data-center deployment or for load sharing.
[ditaa, "NTS-flow", "svg"]
----
- + - - - - - - - - +
- ; Client ;
- ; +-------------+ ; +-------------+
- ; |Bravo | ; |Delta |
- ; |NTS-KE client|-^---------->|NTS-KE server|<-+
- ; +-------------+ ; +-------------+ |
- ; ^ ; | |
- ; | ; | +------------+
- ; | ; | | Admin: Key |
- ; | ; | +------------+
- ; | ; v |
- ; +-----------+ ; +-----------+ |
- ; |Alpha | ; |Charlie |<---+
- ; |NTP client |---^---------->|NTP server |
- ; +-----------+ ; +-----------+
- + - - - - - - - - +
+ /-------------------\
+ | Client |
+ | /---------------\ | /---------------\
+ | | Bravo | | | Delta |
+ | | NTS KE client +------------>| NTS KE server |<-\
+ | \---------------/ | \-----+---------/ |
+ | ^ | | |
+ | | | | /----+------\
+ : | : | | Admin Key |
+ | | | | \----+------/
+ | | | v |
+ | /---+--------\ | /-------------\ |
+ | | Alpha | | | Charlie |<---/
+ | | NTP client +--------------->| NTP server |
+ | \------------/ | \-------------/
+ \-------------------/
----
In this diagram, an arrow means "initiates requests to".
@@ -90,15 +90,23 @@ NTP client to NTS-KE client (Alpha to Bravo) is pretty simple.
As these will both be inside ntpd, this will be function calling,
not a network connection.
- NTS-KE client sends:
- Host name of NTS-KE server
- Optional preferred IP Address 4.1.7
- A sorted list of AEAD algorithms 4.1.5
- It gets back:
- IP Address 4.1.7
- 1 to 8 cookies 4.1.6
- C2S and S2C encryption keys 4.2, 5.1
- The selected AEAD algorithm 4.1.5
+==== NTS-KE client sends:
+- Host name of NTS-KE server
+- Optional preferred 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
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.5[4.1.5]
+
+==== It gets back:
+- IP Address
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.7[4.1.7]
+- 1 to 8 cookies
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.6[4.1.6]
+- C2S and S2C encryption keys
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.2[4.2],
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.1[5.1]
+- The selected AEAD algorithm
+ link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.5[4.1.5]
For AEAD, we need libaes_siv.so, RFC 5297
It's not in OpenSSL yet.
@@ -149,8 +157,9 @@ 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 5.1. This
-process is deterministic, so both ends generate the same C2S and S2C.
+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
server uses them to make the initial cookies.
@@ -164,10 +173,13 @@ NTP client to NTP server (Alpha to Charlie)
If all goes well (no lost packets) the client sends:
- The normal 48 byte NTP packet
- A 32 byte unique ID 5.3
- A cookie 5.4
- Authentication using C2S 5.6
+- The normal 48 byte NTP packet
+- A 32+ byte unique ID
+link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.3[5.3]
+- A cookie
+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.
@@ -178,7 +190,8 @@ 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. 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
@@ -255,7 +268,8 @@ 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. 4.1.6
+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
@@ -272,3 +286,26 @@ needs to be kept private. (aka encrypted if it goes over the net)
Same for NTS-KE server and NTP server.
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.
+
+== Ridiculous questions
+
+=== 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?
+
+=== 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?
+
+Why are The timestamps, unique identifier extension etc. seemingly not tamper resisted?
+
+Can NTSN and other KODs get signed?
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/af0827f6b48c2d22e644762b63180b354c3817fe...eef759027747fe84ef0db50c96c3330b57dc94d5
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/af0827f6b48c2d22e644762b63180b354c3817fe...eef759027747fe84ef0db50c96c3330b57dc94d5
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/20190121/b699e3bc/attachment-0001.html>
More information about the vc
mailing list