[Git][NTPsec/ntpsec][master] 2 commits: compacted SVG and Unicode devel/nts.adoc diagrams
Eric S. Raymond
gitlab at mg.gitlab.com
Sun Mar 3 16:09:27 UTC 2019
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
56295450 by James Browning at 2019-03-03T16:04:18Z
compacted SVG and Unicode devel/nts.adoc diagrams
- - - - -
41427efe by James Browning at 2019-03-03T16:04:18Z
style: replace NTS draft url with macro
- - - - -
2 changed files:
- + devel/NTS-flow.svg
- devel/nts.adoc
Changes:
=====================================
devel/NTS-flow.svg
=====================================
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg xmlns="http://www.w3.org/2000/svg" width="650" height="280" version="1.0" shape-rendering="geometricPrecision">
+<defs>
+<style type="text/css">
+ at font-face{font-family:sans-serif;
+}
+text{font-family:sans-serif;
+font-size:15px;
+stroke:none;
+fill:black;
+}
+.a,.b{stroke-linecap:round;
+stroke-linejoin:round;
+}
+.a{stroke:black;
+stroke-width:1;
+fill:none;
+}
+.b{stroke:none;
+stroke-width:1;
+fill:black;
+}
+.c{stroke:black;
+stroke-width:1;
+stroke-miterlimit:0;
+stroke-linecap:butt;
+stroke-linejoin:round;
+fill:white;
+}
+.d{stroke:rgb(150,150,150);
+fill:rgb(150,150,150);
+filter:url(#shadowBlur);
+}
+</style>
+<filter id="shadowBlur" x="0" y="0" width="200%" height="200%">
+<feOffset in="SourceGraphic" dx="3.0003002" dy="3.0003002" result="offOut"/>
+<feGaussianBlur in="offOut" stdDeviation="3"/>
+</filter>
+</defs>
+<g stroke-width="1" stroke-linecap="square" stroke-linejoin="round">
+<rect x="0" y="0" width="650" height="280" style="fill:white"/>
+<g class="d">
+<path d="M370 105Q365 105 365 98L365 70Q365 63 370 63L520 63L520 63Q525 63 525 70L525 98L525 98Q525 105 520 105L370 105z"/>
+<path d="M65 98Q65 105 70 105L220 105Q225 105 225 98L225 70L225 70Q225 63 220 63L70 63L70 63Q65 63 65 70L65 98z"/>
+<path d="M370 189Q365 189 365 196L365 224Q365 231 370 231L500 231L500 231Q505 231 505 224L505 196L505 196Q505 189 500 189L370 189z"/>
+<path d="M70 231Q65 231 65 224L65 196Q65 189 70 189L190 189L190 189Q195 189 195 196L195 224L195 224Q195 231 190 231L70 231z"/>
+<path d="M620 133Q625 133 625 140L625 154Q625 161 620 161L510 161L510 161Q505 161 505 154L505 140L505 140Q505 133 510 133L620 133z"/>
+</g>
+<path stroke="black" stroke-width="1" stroke-dasharray="5,5" stroke-miterlimit="0" stroke-linecap="butt" stroke-linejoin="round" fill="white" d="M245 77L245 42Q245 35 240 35L50 35L50 35Q45 35 45 42L45 238L45 238Q45 245 50 245L240 245L240 245Q245 245 245 238L245 231L245 231z"/>
+<g class="c">
+<path d="M370 105Q365 105 365 98L365 70Q365 63 370 63L520 63L520 63Q525 63 525 70L525 98L525 98Q525 105 520 105L370 105z"/>
+<path d="M65 98Q65 105 70 105L220 105Q225 105 225 98L225 70L225 70Q225 63 220 63L70 63L70 63Q65 63 65 70L65 98z"/>
+<path d="M370 189Q365 189 365 196L365 224Q365 231 370 231L500 231L500 231Q505 231 505 224L505 196L505 196Q505 189 500 189L370 189z"/>
+<path d="M70 231Q65 231 65 224L65 196Q65 189 70 189L190 189L190 189Q195 189 195 196L195 224L195 224Q195 231 190 231L70 231z"/>
+<path d="M620 133Q625 133 625 140L625 154Q625 161 620 161L510 161L510 161Q505 161 505 154L505 140L505 140Q505 133 510 133L620 133z"/>
+</g>
+<g class="b">
+<path d="M355 84L365 91L355 98z"/>
+<path d="M535 84L525 91L535 98z"/>
+<path d="M105 105L100 119L110 119z"/>
+<path d="M420 175L425 189L430 175z"/>
+<path d="M515 196L505 203L515 210z"/>
+<path d="M355 210L365 217L355 224z"/>
+</g>
+<g class="a">
+<path d="M555 161L555 196Q555 203 550 203L515 203L515 203"/>
+<path d="M535 91L550 91Q555 91 555 98L555 133L555 133"/>
+<path d="M425 175L425 105"/>
+<path d="M355 91L225 91"/>
+<path d="M355 217L195 217"/>
+<path d="M105 189L105 119"/>
+</g>
+<text x="80" y="208">Alpha</text>
+<text x="80" y="222">NTP client</text>
+<text x="380" y="208">Charlie</text>
+<text x="380" y="222">NTP server</text>
+<text x="528" y="152">Admin: Key</text>
+<text x="380" y="82">Delta</text>
+<text x="380" y="96">NTS-KE server</text>
+<text x="80" y="82">Bravo</text>
+<text x="80" y="96">NTS-KE client</text>
+<text x="109" y="54">Client</text>
+</g>
+</svg>
=====================================
devel/nts.adoc
=====================================
@@ -1,3 +1,4 @@
+:draft-nts: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp
= NTS support specification
== Cisco's Statement of Work requirements
@@ -9,8 +10,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
- link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp[NTS]
+* Comply with the standardized specification of link:{draft-nts}[NTS]
* Be interoperable with the other reference implementations in IETF hackathons.
@@ -50,24 +50,25 @@ will both be inside ntpd. In the simple case, Charlie and Delta can
also be packaged together. In complicated cases, Delta could serve multiple
Charlies, e.g. in a data-center deployment or for load sharing.
-[ditaa, "NTS-flow", "svg"]
+image: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 │
+ ║ │ ║ │ └────┬───────┘
+ ║ │ ║ ▼ │
+ ║ ┌───┴────────┐ ║ ┌─────────────┐ │
+ ║ │ Alpha │ ║ │ Charlie │◄───┘
+ ║ │ NTP client ├────╫──────────►│ NTP server │
+ ║ └────────────┘ ║ └─────────────┘
+ ╚═══════════════════╝
----
In this diagram, an arrow means "initiates requests to".
@@ -93,22 +94,17 @@ not a network connection.
==== NTS-KE client sends:
- 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
- link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.5[4.1.5]
+ link:{draft-nts}#section-4.1.7[4.1.7]
+- A sorted list of AEAD algorithms link:{draft-nts}#section-4.1.5[4.1.5]
==== NTS-KE server and NTS-KE client compute from the TLS connection:
-- 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]
+- C2S and S2C encryption keys link:{draft-nts}#section-4.2[4.2],
+ link:{draft-nts}#section-5.1[5.1]
==== NTS-KE client gets back:
-- 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]
-- 1 to 8 cookies
- link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.6[4.1.6]
-- The selected AEAD algorithm
- link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.5[4.1.5]
+- NTPD server hostname or IP Address link:{draft-nts}#section-4.1.7[4.1.7]
+- 1 to 8 cookies link:{draft-nts}#section-4.1.6[4.1.6]
+- The selected AEAD algorithm link:{draft-nts}#section-4.1.5[4.1.5]
For AEAD, we need libaes_siv.so, RFC 5297
It's not in OpenSSL yet.
@@ -162,7 +158,7 @@ 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].
+link:{draft-nts}#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
@@ -178,12 +174,9 @@ 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
-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]
+- A 32+ byte unique ID link:{draft-nts}#section-5.3[5.3]
+- A cookie link:{draft-nts}#section-5.4[5.4]
+- Authentication using C2S link:{draft-nts}#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.
@@ -195,7 +188,7 @@ 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]
+link:{draft-nts}#section-5.5[5.5]
Those slots will be returned with new cookies.
The AEAD algorithm used for authentication is set up to encrypt some
@@ -518,7 +511,7 @@ peer's valid time flag is unset (the server has never given valid time),
discard that time or mark the peer as a falseticker. These checks should
never trigger on legitimate traffic, as that would mean the NTP server
disagrees with its NTS-KE server's CA about time.
-link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-9.3[9.3]
+link:{draft-nts}#section-9.3[9.3]
It might be considered useful to always apply these
`notBefore`/`notAfter` sanity checks, not just for "suspect"
@@ -534,7 +527,7 @@ happen after certificate validation.
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.
-link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.6[4.1.6]
+link:{draft-nts}#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 getting a new pool server or getting new cookies by running
@@ -607,11 +600,11 @@ the encode/decode overhead shouldn't be an issue.
How to make NTS-KE work, securely, with pooled servers?
-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]
+link:{draft-nts}#section-4.1.3[4.1.3], link:{draft-nts}#section-4.1.4[4.1.4]
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]
+link:{draft-nts}#section-5.7[5.7]
Does the unique identifier extension need to be omniversally unique?
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/8a4c241281230599e4de7e8a0756541368271d25...41427efeecb57af356fa103750c9b417b6ff7458
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/8a4c241281230599e4de7e8a0756541368271d25...41427efeecb57af356fa103750c9b417b6ff7458
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/20190303/3159225f/attachment-0001.html>
More information about the vc
mailing list