[ntpwg] Spec markup

[David L. Mills]

Guys,

Something got screwed up when the section on SNTP was added. First, the 
behavior of the SNTP server is defective in case of authentcation 
failure. Second, the section FXMIT section is broken; it never says how 
to copy the received pacekt fields to the transmit packet fields and the 
reference to Figure 21 is broken.

I fixed the problems and added a provision that might have been 
overlooked. The SNTP client implementing symmetric key authentication 
might not want to authenticate the client packet and indicate that by 
stuffing zeros in the digest field of the MAC (can you say MS-SNTP?). I 
made a small wrinkle to support that. If the digest is zero, the packet 
is assumed valid. If not and authentication succeeds, send back an 
authenticated packet. If not and autnentication fails, return a crypto-NAK.

With these changes the NTP server and SNTP server behavior should be 
identical and everybody should be happy.

Details follow. I don't have the sources handy, so could not mark up 
with reference tags.

 >>In Figure 12 on p. 22 and in Figure 32 on p. 56 the GOES line should 
be removed. That service no longer exists. In the first figure the ACTS 
line should be removed. There is to my knowledge no public ACTS service 
other than NIST.

 >>Figure 21 on p. 34 is misplaced. It should go after Figure 22 on p. 36.

 >>Replace entire section FXMIT on p. 34.

FXMIT.  This indicates a client (mode 3) packet matching no association 
(mode 0).  The server constructs a server (mode 4) packet and returns it 
to the client without retaining state. The subsequent behavior at this 
point is identical to the SNTP server described in Section 14.

 >>Bottom of pl 53 just before the table

The MAC, consisting of the x.keyid and x.digest fields is optional. If 
authentication is implemented and p.keyid is nonzero, a MAC is 
constructed using the md5() routine in Appendix A.2 and p.keyid supplied.


 >>p. 55 just before the figure.

Upon receiving a client request, an SNTP primary server constructs and 
sends the reply packet as described in Figure 31and the fast_xmit() 
routine in Appendix A.5.3. Note that the dispersion field in the packet 
header must be updated as described in Section 5.  If the s.rootdelay 
and s.rootdisp system variables are stored in floating double, they must 
be converted to NTP short format first. Client packet fields not used to 
construct the server packet are ignored.

If the destination address is a broadcast address, the client is 
operating in manycast client mode.  If the server stratum is less than 
the client stratum, the server sends an ordinary server (mode 4) packet, 
but using its unicast destination address.  A crypto-NAK is not sent if 
authentication fails.  After these actions the peer process exits.

 >>Just after the figure (proposed for content, may be MUSTed to taste):

A SNTP client implementing the on-wire protocol has a single server and 
no dependent clients.  It is prohibited from sending mode-1 (symmetric 
active), mode-2 (symmetric passive), mode-4 (server) and mode-5 
(broadcast) packets, but can operate with any subset of the NTP on-wire 
protocol, the simplest approach using only the transmit timestamp of the 
server packet and ignoring all other fields.

The MAC, consisting of the r.keyid and r.digest fields is optional. If 
included and r.digest is nonzero, the server computes and verifies the 
digest using the md5() routine in Appendix A.2. If r.digest is zero, the 
packet is assumed correctly authenticated. If authentication succeeds, 
the server constructs a MAC using the same routine and r.keyid supplied.

If authentication fails and the destination address is not a broadcast 
address, the server returns a special message called a crypto-NAK. This 
message includes all the fields in Figure 31, but with a special MAC 
consisting only of the x.keyid field with value zero.  The client MAY 
accept or reject the data in the message. If authentication fails and 
the destination address is a broadcast address, no crypto-NAK message is 
sent and the received packet is discarded.

 >>Section 15, p. 55.

NTPv4 provides an optional authentication field that utilizes the MD5 
algorithm.  MD5, as the case for SHA-1, is derived from MD4, whichhas 
long been known to be weak.  In 2004, techniques for efficiently finding 
collisions in MD5 were announced.  A summary of the appropriateness of 
MD5 can be found in [ref8]. However, even if an alternate text with 
identical digest can be found, it is extremely unlikely that the 
alternate text would have valid on-wire timestamps and header values.

Upon receiving a client request, an SNTP primary server constructs and 
sends the reply packet as described in Figure 31.  Note that the 
dispersion field in the packet header must be updated as described in 
Section 5.