[cifs-protocol] 600548 RE: SNTP issues

[Richard Guthrie]

Andrew,



The link you cite, http://www.cis.udel.edu/~mills/database/reports/ntp4/ntp4.pdf, is related to an implementation of NTPv4.  MS-SNTP is an implementation of NTPv3 as per RFC1305.  In appendix C of the RFC it talks about a field length for the authenticator field of 96 bits.  The MS-SNTP implementation uses an authenticator field length of 160 bits.  If you review the packet layout in section 2.2 of the MS-SNTP document, along with the accompanying text, this section describes the reasoning behind the check of 68 bytes to determine if the request is an MS-SNTP formatted request based on the difference in size of this field.  Used in conjunction with the version field this should alleviate any problems you have in distinguishing the request type.



Hopefully this answers your question.  Thank you for the feedback.



Richard Guthrie

Open Protocols Support Team

Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"

Tel: +1 469 775 7794

E-mail: rguthrie at microsoft.com<mailto:rguthrie at microsoft.com>



-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Saturday, June 14, 2008 4:27 AM
To: Richard Guthrie
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: SNTP issues



On Thu, 2008-06-12 at 09:24 -0700, Richard Guthrie wrote:

> Andrew,

>

>

>

> In response to your question below (highlighted).

>

>

>

>

> Finally, in section 2.2.1 can we have it specified that instead of

> 'the server must ignore this subfield' (and implying that the client

> might fill it with a checksum), that the client MUST zero this

> subfield, and the server MAY use the presence of zeros to indicate use

> of Microsoft's SNTP extensions'.

>

>

>

> This should not require a change of Microsoft's code, but will allow

> servers to easily determine if they should process an incoming packet

> with RFC-standard MD5 signing of the NTP packet, or Microsoft's

> varient.

>

>

>

> Answer

>

>

>

>

> Section 3.2.5 of the MS-SNTP documentation covers the exact scenario

> you describe.  You can distinguish whether the request is an RFC1305

> NTP request or SNTP request based on the length of the message.  Here

> is the relevant text from the documentation:



It is not possible to distinguish between the MD5 authentication used by the internet NTP community and Microsoft's MD5 authentication by using the length.



> When the server receives the Client NTP Request message from the

> client, the server examines the NTP message length. The Authenticator

> field that the NTP Authentication Extensions specify is present if the

> NTP message length is 68 bytes. In this case, the server MUST respond

> with an authenticated NTP response. Any other message length is

> processed as specified in [RFC1305] section 3.4.3.<14>

>

>

>

> I think this covers your original question, if not let me know.



It does not.  Returning to my original question:



> Finally, in section 2.2.1 can we have it specified that instead of

> 'the server must ignore this subfield' (and implying that the client

> might fill it with a checksum), that the client MUST zero this

> subfield, and the server MAY use the presence of zeros to indicate use

> of Microsoft's SNTP extensions'.

>

>

>

> This should not require a change of Microsoft's code, but will allow

> servers to easily determine if they should process an incoming packet

> with RFC-standard MD5 signing of the NTP packet, or Microsoft's

> varient.



Perhaps a read of the NTP code available on www.ntp.org or a question to the NTP working group might provide some education?



Also see appendix A of:

http://www.cis.udel.edu/~mills/database/reports/ntp4/ntp4.pdf



This shows a packet format identical in length to Microsoft's extension.

It is possible to detect Microsoft's extension by the presence of zeros (a highly unlikely MD5 digest) in client messages.  I am asking that this detection remain possible, by enforced wording in your specification.



Thanks,



Andrew Bartlett



--

Andrew Bartlett                                http://samba.org/~abartlet/

Authentication Developer, Samba Team           http://samba.org

Samba Developer, Red Hat Inc.                  http://redhat.com


-------------- next part --------------
HTML attachment scrubbed and removed