[cifs-protocol] Re: [Pfif] SNTP issues

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080618/dfd78861/attachment-0001.bin