[ntp:hackers] [Bug 1242] --enable-wintime should be enabled by default on all target systems

David Mills mills at udel.edu
Mon Jul 6 03:39:58 UTC 2009


Dave,

In the Samba agenda I requested the same rules be followed as in the 
Autokey agenda. Both define an optional extended state machine.

1. If the code was ifdeffed out, nothing whatsoever remains in the code 
base with the possible exception of a define or two for convenience. 
This is the case with Autokey, it could be the case for Samba - see below.

2. If the code was ifderred in, its functionality is completely disabled 
and the state machine operates as if it was not there for ordinary 
packets defined in the specification.  For Autokey this is indicated in 
the key ID space; this is incompatible with Samba, which needs to use 
the whole space. For Samba the extensions are enabled if a packet with a 
MAC of all zeros. In earlier messages I suggested this is not a 
particularly good idea; a much better one would be to extend the 
crypto-nak, which at present requires a zero value for this function. 
However, other codes could be made available and mapped to NONE in the 
input routine. The output routine iffdeffed segment would look for that 
code and act like it does now with the FLAG_ADKEY. A whole lot of 
confusing and intricate code would go away and the code would be much 
easier to read and document,.

3. An inbound packet to the extended state machine must be distinguished 
in such a way it cannot be mistaken as an ordinary packet. An outbound 
packe from the extended state machine must be explicitly configured. For 
Autokey this is done using the crypto command. For Samba there is not 
such need, since a Samba association will never be configured.

4. If the extended state machine is not available or disabled and an 
extended state machine packet shows up, it must be silently discarded. 
This is the case with Autokey, but not now the case with Samba as now 
implemented. See below.

There are three ifdeffed code segments in ntp_proto.c concerned with Samba:

Line 562 lit by WINTIME: Set a bit if the mode is client or passive 
packet matches no association. Also set the authentication to none.

Line 930 lit by WINTIME: Return a symmetric passive packet unless the  
NOTRUST access bit is lit.

Line 3260 lit by HAVE_NTP_SIGND: Test the FLAG_ADKEY and call the signer 
if set, then exit the output routine.

Discussion:

1. The use of WINTIME at line 562 is not a good idea. Better to use 
HAVE_NTP_SIGND instead. This completely disables the FLAG_ADKEY and 
preserves the original state machine. If a Samba packet shows up and 
Samba either unabailable or explicitly disabled (by a configuration 
command like cryupto), the state machine returns a crypto_nak, which in 
fact might be useful for the Samba user in the first place. If this were 
done the FLAG_ADKEY could be moved entirely within the line 3260 segment 
so no traces of Samba would appear if not available. If available but 
disabled, a FLAG_ADKEY could never show up and the state machine would 
be preserved.

2. The segment at line 930 is troubling. Apparently, Windows makes a 
distinction between client and peer modes, expecting them both to elicit 
identical behavior at the server. First, the spec and state machine say 
a legitimate respons to a symmetric active packet is either a symmetric 
active or symmetric passive packet, so a Windows client should not be 
surprised to see that. Second, the way the code is written a received 
crypto-nak will cause a legitimate symmetric passive packet to be sent, 
which is a clear protocol violation. You can say this will never happen, 
but I have spent a lot of hours closing doors like this.

I orignally disabled this section because of these problems, but it 
should be possible to fix them and remove the ifdef entirely. The 
problem is that is wickedly complicated by the various access bits. What 
happens if a symmetric active Samba packet shows up and the access bits 
say NOTRUST and NOPEER? This is not just a Samba problem, just minor 
modifications to the state machine. But, such modifications should be 
done is a consistent way.

Dave

Dave Hart via the NTP Bugzilla wrote:

>http://bugs.ntp.org/1242
>
>
>hart at ntp.org changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>               Flag|blocking4.2.6?              |blocking4.2.6?(burnicki at ntp.
>                   |                            |org)
>
>
>----------------------------------------------------------------------------
>Additional Comments From hart at ntp.org (Dave Hart)
>Submitted on 2009-07-06 00:04
>
>(In reply to Martin's comment #16)
>
>>Dave,
>>
>>(In reply to Dave Mills' comment #14)
>>
>>>Then, the Samba folks hijacked the ifdef, but I didn't 
>>>notice it.  If I had, I would have squawked. The two uses of WINTIME 
>>>should be separated;
>>>
>>I absolutely agree. A different symbol should be used to control support for 
>>
>MS 
>
>>authentication.
>>
>
>Dave & Martin:  It's not fair to describe the interaction of WINTIME and the 
>Samba "signd" extension to implement the Microsoft-style signed NTP documented 
>in [MS-SNTP] as hijacking WINTIME.
>
>By the nature of the problem space (time providers being authenticated to 
>clients via a shared secret managed automatically for machines joined to a 
>Windows domain), the Samba signd implementation requires the WINTIME workaround 
>be enabled.  This is because regardless of the ntp.dns.name,0x8 workaround to 
>use client mode documented in Microsoft's KB article, when a Windows domain 
>member attempts to synchronize its time to the domain (or domain controllers, if 
>you prefer), they sent symmetric mode requests that look to ntpd like an attempt 
>to authenticate using keyid 0 with an all-zeros MD5 hash.  For Samba's DC 
>emulation to properly fulfill the [MS-SNTP] NTP server role using ntpd, ntpd 
>must be able to be configured to respond to those requests (and possibly sign 
>the response).
>
>The Samba folks, with review by Harlan and myself, carefully separated what code 
>is needed for the WINTIME workaround from what is needed for Samba DC emulation, 
>conditionalizing the latter under #ifdef HAVE_NTP_SIGND.  While there is signd-
>related code to set flags = FLAG_ADKEY that is not under HAVE_NTP_SIGND, this 
>codepath occurs only when a Windows domain member is asking what it believes to 
>be a domain controller to provide a signed NTP symmetric reply.  Without 
>HAVE_NTP_SIGND configured, the packet is dropped on the floor a bit later in the 
>routine.  The requirement for WINTIME to be enabled for this code to be included 
>is correct.
>
>I should also note that the Samba folks have clearly expressed a preference to 
>see both the WINTIME and HAVE_NTP_SIGND conditionalized code be included by 
>default and controlled by runtime switches or ntp.conf knobs.  To that end, even 
>if you build with WINTIME and HAVE_NTP_SIGND, you must separately use a ntp.conf 
>directive to enable ntpd to attempt to do its part in emulating a Windows domain 
>controller with Samba's assistance.  For them as a practical matter requiring 
>users who wish to configure their DC emulation to rebuild ntpd from source with 
>different ./configure options is a roadblock to testing and adoption.
>
>
>>>the symmetric active ifdef should default to off 
>>>unless somebody complains.
>>>
>>I'm one of those who are complaining ... ;-)
>>
>
>



More information about the hackers mailing list