[cifs-protocol] RE: SNTP issues

Richard Guthrie rguthrie at microsoft.com
Thu Jun 12 16:24:57 GMT 2008


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:



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.

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: Richard Guthrie
Sent: Tuesday, May 27, 2008 5:30 PM
To: Andrew Bartlett
Cc: pfif at tridgell.net
Subject: RE: SNTP issues



Andrew,



In doing some research around the questions below, with respect to question 2, I came across the following technet article that talks about various scenarios in which SNTP is used in a windows environment.  Does this reference answer your question around where this protocol would be deployed?



http://technet2.microsoft.com/windowsserver/en/library/0dcdbdc2-363e-4cd3-bba7-7853499f46e21033.mspx?mfr=true



Richard Guthrie

Microsoft Open Protocol Support Team

Work #: +1 469-775-7794



-----Original Message-----

From: Andrew Bartlett [mailto:abartlet at samba.org]

Sent: Sunday, May 25, 2008 9:12 PM

To: Richard Guthrie

Cc: pfif at tridgell.net

Subject: RE: SNTP issues



On Fri, 2008-05-23 at 12:15 -0700, Richard Guthrie wrote:

> Andrew,

>

>

>

> My name is Richard Guthrie, and I support customers working to develop

> solutions against our Open Protocol specifications.  To get started I

> want to ensure I have accurately captured your request.  I think I see

> three separate questions in your email:

>

>

>

> 1.  In section 5.1 there is no mention of how or whether the protocol

> prevents replay attacks.  You would like to see clarifying text in the

> document around this topic as to whether there is any support and if

> not that it is stated in section 5.1.  In addition, at the end of

> section 5.1 is a link to note 17, there is not a lot of clarity

> between note 17 and the text it is linked to in section 5.1.



Yep.



> 2.  With regard to your statement “Also, the stateless use of the

> long-term arcfour-hmac-md5 keys is a security risk, and while nothing

> will change how this has been deployed to date, perhaps a note should

> be added that this protocol should not be used except in windows

> domains,” is this a request to look at an x.509 based

> authentication/encryption architecture for this protocol in the future

> with regards to SNTP?  I would be happy to look into filing that as a

> request with the associated product team.  I will also look into

> getting clarity on when it is appropriate to deploy this protocol and

> let you know the results.



Yes.  There is an existing internet standard for X.509 based authentication here.



> 3.  Section 2.2.1 should state that the client NTP request is expected

> in network byte order.  The byte order of the key identifier is

> already specified.



Yeah, and the person who decided to switch the byte order of just one field should be hung, drawn and quartered, but perhaps that is beyond your remit ;-)





> Hopefully, I have captured your request correctly.  If not feel free

> to correct me where there is inaccuracy so I may best help you get the

> answers you need.  You may or may not know but Monday is a holiday in

> the U.S. so I will be returning to the office on Tuesday to continue

> working with this issue.



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.



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 --------------

3j�Zr���
���y��v�����


More information about the cifs-protocol mailing list