Andrew, As per our discussio, I completed my investigation of this issue. The last part of your question was around section 2.2 of the MS-SNTP documentation and the use of the term 'little-Endian' for the Key Identifier field. The documentation failed to cover what the byte order was for the remaining fields in the request/response messages. To correct this issue we have have added a statement to section 2.2 that reads as follows:
Note In accordance with [RFC1305], all fields are in big-endian (network byte order) format unless otherwise specified. Thank you helping us improve the documentation set. 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: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted From: Richard Guthrie (180Squared Inc.) Sent: Friday, May 23, 2008 2:16 PM To: 'Andrew Bartlett' Cc: [EMAIL PROTECTED] Subject: RE: SNTP issues 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. 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. 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. 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. Richard Guthrie Microsoft Open Protocol Support Team Work #: +1 469-775-7794 -----Original Message----- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, May 23, 2008 7:16 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED] Subject: SNTP issues So, I've moved on from 'netlogon' packets to NTP. MS-SNTP 5.1 Security Considerations for Implementers This section lacks some critical considerations for implementers. Firstly, nothing in the protocol seems to prevent replay attacks, so an attacker can save away packets, and then reset the client's time back to a time in the past. Note 17 indicates that windows clients will happily accept that packet. 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... (A more secure alternative would involve an X.509 infrastructure and moving to the AutoKey protocol) It would also be nice if it were noted more clearly in 2.2.1 Client NTP Request that the 'key identifier' being little endian is a deviation from the rest of the protocol - which presents all quantities in network byte order. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
