[Git][NTPsec/ntpsec][master] Free ntp.packet comments of SHA-1, md5, and des.

[Hal Murray (@hal.murray)]

Hal Murray pushed to branch master at NTPsec / ntpsec


Commits:
a3a04714 by James Browning at 2023-11-30T01:24:07+00:00
Free ntp.packet comments of SHA-1, md5, and des.

- - - - -


2 changed files:

- pylib/packet.py
- tests/pylib/test_packet.py


Changes:

=====================================
pylib/packet.py
=====================================
@@ -56,7 +56,7 @@ the general structure of an NTP packet (Figure 8):
       |                          Key Identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
-      |                           digest (128)                        |
+      |                          MAC (128/160)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
@@ -143,17 +143,16 @@ If you look at the raw data, there are 3 unknowns:
    * clock offset
 but there are only two equations, so you can't solve it.
 
-NTP gets the 3rd equation by assuming the transit times are equal.  That lets
-it solve for the clock offset.
+NTP gets the 3rd equation by assuming the transit times are equal.  That 
+lets it solve for the clock offset.
 
-If you assume that both clocks are accurate which is reasonable if you have
-GPS at both ends, then you can easily solve for the transit times in each
-direction.
+If you assume that both clocks are accurate which is reasonable if you 
+have GPS at both ends, then you can easily solve for the transit times 
+in each direction.
 
-The RFC 5905 diagram is slightly out of date in that the digest header assumes
-a 128-bit (16-octet) MD5 hash, but it is also possible for the field to be a
-128-bit AES_CMAC hash or 160-bit (20-octet) SHA-1 hash.  NTPsec will
-support any 128- or 160-bit MAC type in libcrypto.
+The RFC 5905 diagram is slightly out of date in that the MAC header 
+assumes a 128 or 160-bit (16 or 20-octet) MAC. NTPsec supports all 
+appropriate algorithms in libcrypto.
 
 An extension field consists of a 16-bit network-order type field
 length, followed by a 16-bit network-order payload length in octets,
@@ -189,7 +188,7 @@ Here's what a Mode 6 packet looks like:
       |                          Key Identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
-      |                           digest (128)                        |
+      |                          MAC (128/160)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
@@ -359,16 +358,14 @@ class SyncPacket(Packet):
          self.transmit_timestamp) = struct.unpack(
             SyncPacket.format, data[:SyncPacket.HEADER_LEN])
         self.extension = data[SyncPacket.HEADER_LEN:]
-        # Parse the extension field if present. We figure out whether
-        # an extension field is present by measuring the MAC size. If
-        # the number of 4-octet words following the packet header is
-        # 0, no MAC is present and the packet is not authenticated. If
-        # 1, the packet is a crypto-NAK; if 3, the packet is
-        # authenticated with DES; if 5, the packet is authenticated
-        # with MD5; if 6, the packet is authenticated with SHA1. If 2
-        # or 4, the packet is a runt and discarded forthwith. If
-        # greater than 6, an extension field is present, so we
-        # subtract the length of the field and go around again.
+        # Parse any present extension fields. We determine the presence
+        # of an extension field by measuring the trailer size. If the
+        # number of 4-octet words following the packet header is 0, there
+        # is no MAC, and the packet is unauthenticated. If 1, the missive
+        # is a crypto-NAK; if 5 or 6, register authentication. If 2, 3, or
+        # 4 the datagram is a runt and discarded immediately. If greater
+        # than 6, an extension field is present, so we subtract the fields'
+        # length and repeat.
         payload = self.extension  # Keep extension intact for flatten()
         while len(payload) > 24:
             (ftype, flen) = struct.unpack("!II", payload[:8])
@@ -376,11 +373,9 @@ class SyncPacket(Packet):
             payload = payload[8+flen:]
         if len(payload) == 4:    # Crypto-NAK
             self.mac = payload
-        elif len(payload) == 12:   # DES
-            raise SyncException("Unsupported DES authentication")
-        elif len(payload) in (8, 16):
+        elif len(payload) in (8, 12, 16):
             raise SyncException("Packet is a runt")
-        elif len(payload) in (20, 24):   # MD5 or SHA1
+        elif len(payload) in (20, 24):   # Symmetric authentication
             self.mac = payload
 
     @staticmethod


=====================================
tests/pylib/test_packet.py
=====================================
@@ -328,7 +328,7 @@ class TestSyncPacket(unittest.TestCase):
             errored = False
         except ntpp.SyncException as e:
             errored = e.message
-        self.assertEqual(errored, "Unsupported DES authentication")
+        self.assertEqual(errored, "Packet is a runt")
         # Test with extension, runt 8
         data2 = data + ext + "\x11\x22\x33\x44\x55\x66\x77\x88"
         try:



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/-/commit/a3a047142ca6588b885c979c74f52167d00c28ff

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/-/commit/a3a047142ca6588b885c979c74f52167d00c28ff
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/20231130/162a6a98/attachment-0001.htm>