On Sat, 2008-06-14 at 19:27 +1000, Andrew Bartlett wrote: > 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.
Furthermore, it would allow a slightly useful answer to the question you promised to follow up (for someone else) on the MSDN forums: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3463004&SiteID=1 This post similarly requests a method to distinguish Microsoft's clients into the future. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
