[ntp:questions] Our NTP Client is not working with MeinBerg Daemon Server - Is it due to wrong implementation ?
Emmanuel, Mathews IN BLR SISL
Mathews.Emmannuel at siemens.com
Fri Jan 29 05:01:18 UTC 2010
Thanks for your valuable time and I may be requesting more time from you.
I receive the Crypto-NAK even when the ntpd client is stopped. My primary issue is Our NTP client always returns a Crypto-NAK for its time request while talking to ntpd Daemon Server.
I have mentioned the simultaneous use of two clients, only to explain the different cookie generation for different clients in the same machine.
With best regards,
From: Dave Hart [mailto:davehart at gmail.com]
Sent: Friday, January 29, 2010 1:51 AM
To: Emmanuel, Mathews IN BLR SISL
Subject: Re: [ntp:questions] Our NTP Clinet is not working with MeinBerg Daemon Server - Is it due to wrong implementation ?
You might see if the CRYPTO-NAKs cease if you stop the ntpd on the
client -- perhaps autokey doesn't like talking to two clients on the
same IP address?
On Thu, Jan 28, 2010 at 10:12 AM, Emmanuel, Mathews IN BLR SISL
<Mathews.Emmannuel at siemens.com> wrote:
> I am using MeinBerg NTP Daemon server to test our NTPV4 client which supports MD5 (128 bit) hashing and Auto Key. I am able to send and receive the message packets till the cookie message response.
> Once I receive the cookie response and after decrypting and verifying the cookie, I am sending the time request to the NTP daemon Server. How ever I always get a CRYPTO-NAK reply from the NTP Daemon server, which means the MAC validation failed in the server side.
> I am not able to understand why the MAC validation is failing only for time request and it always returns a success response with ASSOC, CERT and COOKIE requests. I am using the same logic for MAC generation in ASSOC, CERT, COOKIE and Time Request. The only difference is the time request uses the cookie as private value to generate the KeyValue where in ASSOC ,CERT and COOKIE request it is zero.
> 1. Is there any difference in the logic of generating the MAC in Time request compare to ASSOC, CERT and Cookie?
> Let me explain the logic that I use to generate the MAC for a request.
> * First Generate the KeyValue by using 'KeyValue = MD5 (Client IP+ Server IP + KeyID + Cookie) ', in case of ASSOC, CERT and COOKIE requests, the value of Cookie is zero.
> * Generate the Digest using Digest = MD5 (KeyValue + (NTP Header + Extension)) where Extension is NULL for Time Request.
> * The MAC includes the KeyID and Digest (Total 20 bytes).
> 2. Is the above logic correct? If correct why I am getting a CRYPT-NAK time response?
> One more point I have noticed in Meinberg NTP Daemon server is that, it generate different cookies for each client which run in the same PC. How it is possible to generate different cookie without saving the session details of the client in the NTP Daemon Server? Cookie is always generated with MD5 ( ClientIP + Server IP + KeyID (0) + Server Seed ) . As per my understanding the cookie should be same for all the clients which run from the same machine until and unless the Server seed is regenerated.
> Let me explain how I have done this experiment. I have Meinberg NTP Daemon server in PC1 and 'Meinberg NTP Daemon Client' and our 'NTP Client' running in PC2.
> Now I have started NTP Daemon Server in PC1, Then NTP Daemon Client in PC2. Now NTP Daemon client received the cookie Cookie1 and started synchronizing the time. Now I have started our NTP Client in PC2 i.e. two clients are running in PC2 and communicating to the server in PC1. Our NTP client received a cookie Cookie2 which is different than that of Cookie1. As per my understanding both clients should receive the same cookie until and unless the Server seed is regenerated. If the server seed is regenerated time request from NTP Daemon server should fail as the cookie is changed due to server seed regeneration. For my surprise NTP Daemon client is still synchronizing the time and Our NTP Client receives a Crypto-NAK as usual.
> I am not able to understand how it is possible in a client-server communication where the server do not save the session details of the client.
> Please let me know if any one can help me out in this regard.
> I am not able to understand whether the problem is with my implementation or something else?
> With best regards,
> Mathews Emmanuel
> Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
> Thank You.
> questions mailing list
> questions at lists.ntp.org
Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
More information about the questions