[Git][NTPsec/ntpsec][master] 2 commits: Grammar, some formatting for clarity

Tue Oct 2 19:09:23 UTC 2018

James Browning pushed to branch master at NTPsec / ntpsec


Commits:
e75ee04e by Paul Theodoropoulos at 2018-10-02T18:16:04Z
 Grammar, some formatting for clarity

- - - - -
4310c0bb by Paul Theodoropoulos at 2018-10-02T18:43:25Z
WIP significant rewording and reworking of examples

- - - - -


1 changed file:

- docs/authentic.txt


Changes:

=====================================
docs/authentic.txt
=====================================
@@ -30,8 +30,8 @@ include::includes/authopt.txt[]
 == Introduction ==
 
 Authentication support allows the NTP client to verify that the server
-is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server.  NTP performs
+is in fact known and trusted and not an intruder accidentally
+or intentionally masquerading as that server.  NTP performs
 authentication via message digests. It computes a one-way hash, which
 verifies that the server has the correct private key and key identifier.
 
@@ -45,7 +45,7 @@ options described below specify the locations of the key files and
 which symmetric keys are trusted.
 
 Authentication is always enabled, although ineffective if not configured
-as described below. If a NTP packet arrives including a message
+as described below. If an NTP packet arrives including a message
 authentication code (MAC), it is accepted only if it passes all
 cryptographic checks. The checks require correct key ID, key value and
 message digest. If the packet has been modified in any way
@@ -55,9 +55,9 @@ discarded.  Authentication doesn't prevent replays.
 [[symm]]
 === Symmetric-Key Cryptography ===
 
-NTP allows any one of possibly 65,535 keys, each distinguished by a
-32-bit key identifier, to authenticate an association. The servers and
-clients involved must agree on the key and key identifier to
+NTP allows use of any one of possibly 65,535 keys, each distinguished by a
+32-bit key identifier, to authenticate an association. Both server and
+client must agree on the key and key identifier in order to
 authenticate NTP packets. Keys and related information are specified
 in a key file. More info in {ntpkeysman}. It must be distributed
 and stored using secure means beyond the scope of the NTP protocol
@@ -81,31 +81,34 @@ A server receiving an unauthenticated packet will respond with an
 unauthenticated packet, while the same server receiving a packet of a
 cryptotype it supports will respond with packets of that cryptotype.
 
-Some examples may help to reduce confusion. Client Alice has no
-keys file. Server Bob has a symmetric key file.
-Alice's unauthenticated messages arrive at Bob,
-who replies with unauthenticated messages. Cathy has a copy of Bob's
-symmetric key file and has selected key ID 4 in messages to Bob. Bob
-verifies the message with his key ID 4. If it's the same key and the
-message is verified, Bob sends Cathy a reply authenticated with that
-key. If verification fails, Bob sends Cathy a crypto-NAK,
-which tells her something broke. She can see the evidence using the
-{ntpqman} program.
-
-It should be clear from the above that Bob can support all the girls at
-the same time, as long as he has compatible authentication and identity
-credentials. Now, Bob can act just like the girls in his own choice of
-servers; he can run multiple configured associations with multiple
-different servers (or the same server, although that might not be
-useful). But, wise security policy might preclude some combinations;
-for instance, running authentication with one server
-and no authentication with another might not be wise.
+Some examples may help to reduce confusion.
+
+Client Alice has no key file. Server Bob has a symmetric key file.
+Alice sends an unauthenticated message to Bob. Bob therefore replies
+also with an unauthenticated message.
+
+Client Carol does have a copy of Bob's symmetric key file. Carol selects
+key ID 4, and sends a message to Bob. Bob verifies the message with his
+key ID 4. If the key matches and the message verifies, Bob replies to
+Carol with a message authenticated with his key ID 4. If verification fails,
+Bob sends Carol a crypto-NAK, which tells her that something is broken.
+She can see the evidence using the {ntpqman} program.
+
+It should be clear from the above that Bob can support both unauthenticated
+Alice and authenticated Carol alike. Unauthenticated messages will 
+receive unauthenticated replies. Authenticated messages will receive
+authenticated replies, assuming the authentication method and credentials
+are valid and compatible.
+
+Bob also can act just like Alice and Carol in his own choice of connections
+to other servers; he can run multiple configured associations with multiple
+different servers (or the same server, although that might not be useful).
 
 [[keys]]
 == Key Management ==
 
 Shared keys used for authentication are incorporated
-keys files generated by the {ntpkeygenman} utility
+into the keys files generated by the {ntpkeygenman} utility
 program.
 
 [[algorithms]]
@@ -115,10 +118,9 @@ The NTP standards include symmetric (private-key) authentication using
 any message digest algorithm supported by the OpenSSL package.
 Digests longer than 20 bytes will be truncated.
 This algorithm computes a message digest or one-way hash
-which can be used to verify the client has the same message digest as
+which can be used to verify that the client has the same message digest as
 the server.
 
-
 Authentication is configured separately for each association using the
 +key+ option of the +server+ configuration command, as
 described in the link:confopt.html[Server Options] page. The
@@ -165,7 +167,6 @@ AES needs a 16 byte key.  Longer keys are truncated.  Shorter
 keys are padded with 0s.  AES MACs are 16 bytes long.  MACs longer
 than 20 bytes will be truncated.
 
-
 Keys and related information are specified in a keys file, which must be
 distributed and stored using secure means beyond the scope of the NTP
 protocol itself. Besides the keys used for ordinary NTP associations,



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/03adfbe2dea9161b4f4b019a62d90b83f967c695...4310c0bbe5588e381e23b44f4172acd9e98284cf

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/03adfbe2dea9161b4f4b019a62d90b83f967c695...4310c0bbe5588e381e23b44f4172acd9e98284cf
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/20181002/47942624/attachment-0001.html>
