Hi Dave, 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, Mathews Emmanuel -----Original Message----- From: Dave Hart [mailto:[email protected]] 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? Cheers, Dave Hart On Thu, Jan 28, 2010 at 10:12 AM, Emmanuel, Mathews IN BLR SISL <[email protected]> wrote: > Hello, > > 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 > [email protected] > http://lists.ntp.org/listinfo/questions > 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 [email protected] http://lists.ntp.org/listinfo/questions
