[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	11022
Summary	NTP decoding has dups, misses authentication
Product	Wireshark
Version	1.12.3
Hardware	x86
OS	Fedora
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	tlhackque@yahoo.com

Created attachment 13483 [details]
2 packet trace showing authenticated request and failure reply.

Build Information:
Version 1.12.3 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.25, with Cairo 1.13.1, with Pango 1.36.8, with
GLib 2.42.1, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux),
without libnl, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, without
Python,
with GnuTLS 3.3.11, with Gcrypt 1.6.1, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Aug 18 2014 05:50:44), with AirPcap.

Running on Linux 3.18.6-200.fc21.x86_64, with locale en_US.UTF-8, with libpcap
version 1.6.2, with libz 1.2.8, GnuTLS 3.3.12, Gcrypt 1.6.1, without AirPcap.
Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz

Built using gcc 4.9.2 20141101 (Red Hat 4.9.2-1).

Wireshark is Open Source Software released under the GNU General Public
License.
--
NTP Decode of the attached trace shows the following divots:

1) In the Data section, we see the data replicated, although it's only in the
packet data once.  Both request & reply.  Here's the reply:
   clk_wander_threshold=0.100\r\n
     clk_wander_threshold=0.100\r\n
       clk_wander_threshold
       =
       0.100
         0.100
           0.100

2) The request packet carries authentication data, but this is not displayed as
a decoded field.  I don't expect validation as Wireshark doesn't have the key. 
But it should say something like 

"Authenticated packet", and break out the authenticator
+ Authenticator
  + KeyType: MD5 
  + KeyIndex: 124 (0x0000007b)
  + Signature: 08 b6 d0 9b ed bf c5 81 0b e7 83 72 07 a9 16 64

See RFC 1305 + the ntp sources.  ntp.h, ntp_control.h, and ntp_control.c 

Basic scheme is for symmetric key auth is that the authentication data is the
packet length - length in the NTP header.  4 bytes are the key index.  The
authentication scheme is implicit in the remaining length.  

In this case, we have 52 byes of NTP data: 12 bytes header + 20 bytes data = ""
bytes basic payload.  52 - 32 = 20 bytes of authentication.  

auth = 4 bytes key, leaving 16 bytes of signature.

Since the length is 16, the signature is MD5.
For SHA there would be 20.

If you wish to validate, the key used in this trace is "Secret".

To send such a packet, run ntpq and enter
ntpq> authenticate yes
ntpq> keyid 123
ntpq> keytype md5 (or sha)
ntpq> passw Secret
ntpq> rv 0 clk_wander_threshold

For autokey - it's more complicated, rarely used, and about to be deprecated.

---

      You are receiving this mail because:

• You are watching all bug changes.