[Git][NTPsec/ntpsec][master] More updates.

Hal Murray gitlab at mg.gitlab.com
Fri Jan 18 10:26:03 UTC 2019


Hal Murray pushed to branch master at NTPsec / ntpsec


Commits:
52ef9b62 by Hal Murray at 2019-01-18T10:23:23Z
More updates.

- - - - -


1 changed file:

- devel/nts.adoc


Changes:

=====================================
devel/nts.adoc
=====================================
@@ -18,13 +18,13 @@ The NTS implementation shall:
 
 The NTP server maintains no per-client state.  The NTP client
 stores the state in a cookie which is sent with each request.
-The cookie is provided by the KE server.  The NTP server will
+The cookie is provided by the NTS-KE server.  The NTP server will
 decrypt it to recover the session keys.
 
-NTS should not assist tracking of the client.  (Consider
-a laptop that moves from home to work to a coffee shop.)
-Thus cookies should only used once.  Each NTP response returns
-a new encrypted 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 implement that, each NTP response includes a new encrypted cookie.
 
 NTS should not assist DDoS amplification.  All NTP responses
 are the same length as the request.  This means that some
@@ -61,7 +61,9 @@ deployment.
 ----
 
 In this diagram, an arrow means "initiates requests to". 
-Responses may flow in the other direction.
+Responses flow in the other direction.  Each connection
+is used for one request/response transaction.
+
 
 === Alpha -> Bravo ===
 NTP-client to NTS-KE-client (Alpha to Bravo) is pretty simple.
@@ -85,9 +87,24 @@ NTS-client has to make the C2S and S2C keys.  They are tangled up
 with TLS.
 
 === Echo -> Charlie & Delta ===
+In this mode, the NTS server generates the cookies, and thus
+must know the master key and the cookie generation recipe.
+
 Echo to the servers Charlie and Delta is a one shot.
 Echo sends a seed/ratchet mechanism number pair to both servers.
-optionally a rotation time and cookie format number could be sent. 
+optionally a rotation time and cookie format number could be sent.
+
+=== Or... dump the Echo box
+In this mode, the NTS-server doesn't know the master key
+or the cookie format.
+
+NTS-server to NTP-server
+  NTS-Server sends:
+    C2S and S2C encryption keys  4.2, 5.1
+    A sorted list of AEAD algorithms  4.1.5
+  It gets back:
+    The selected AEAD algorithm 4.1.5
+    1 to 8 cookies  4.1.6
 
 === Alpha -> Charlie ===
 NTP-client to NTP-server (Alpha to Charlie)
@@ -102,6 +119,8 @@ If all goes well (no lost packets) the client sends:
 It gets back the same, with the cookie replaced with a new cookie
 and S2C used for authentication.
 New cookies are encrypted with S2C.  Pg 20
+The response is the same lengh.  The cookie is moved from
+unencrypted to encrypted.
 
 All the extra data is in real NTP extensions.  (No more of
 the magic length kludgery for the current shared key authentication.)
@@ -111,7 +130,8 @@ a cookie-placeholder for each extra cookie it wants.  5.5
 Those slots will be returned with new cookies.
 
 The AEAD algorithm is setup to encrypt some data as well as authenticate.
-I don't know of any reason to use that.  (Hal, Jan 14)
+For the request, that's empty.  For the response, it contains a new
+cookie.  (Or cookies.)
 I think we need a nonce in there.
 
 == Key Generation and Usage ==
@@ -152,3 +172,14 @@ 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
 NTS-KE again.
 
+---
+
+We need an exponential backoff when the NTS-KE step fails.
+
+---
+
+Note that the communication between NTS-KE client and NTP client
+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.
+



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/52ef9b623629f3f337c1044657539ff2406b7921

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/52ef9b623629f3f337c1044657539ff2406b7921
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/20190118/fc66f7d5/attachment-0001.html>


More information about the vc mailing list