[cryptography] Authenticated Time Synchronization
natanael.l at gmail.com
Mon Sep 2 05:46:34 EDT 2013
If the server isn't trusted enough to be allowed to know how many
devices there are behind one proxy/IP address, then cookies should
never be reused, otherwise it might be able to tell that there's
simultaneously maybe 5 or so different cookies being used when sending
time requests from the same IP. In that case it should only be used as
a single-round protocol. Or you set up a local time server for all
local computers to use, but I'm not sure that would work everywhere
(such as for hotspots, can't always get the client to use your local
Exactly how untrusted is the server assumed to be?
2013/9/1 Stephen Röttger <stephen.roettger at gmail.com>:
> Hi Everyone,
> We're currently working on a new RFC for authenticated time
> synchronization (NTP/PTP) since the current approach has major security
> vulnerabilities and would like to have some feedback.
> You can find the most recent version of the draft here:
> And the previous discussion on the mailing list of the working group:
> I would be especially interested in feedback for the client-server
> synchronization and will outline the protocol shortly.
> The major requirements for this protocol are as follows:
> * the server should not keep a state about the clients
> * it shouldn't be a cpu hog (in order to not influence the
> synchronization precision)
> That's why we came up with the following protocol:
> The server keeps a 128 bit secret S_s and has a public key and a
> certificate signed by some certificate authority.
> C -> S: request a shared secret (cookie request)
> The client sends his public rsa key C_pub to the server
> C <- S: cookie response
> The server calculates a secret, unique to the client:
> C_cookie = MSB_128(S_s || H(C_pub))
> And sends it back to the client, encrypted with C_pub and signed
> C -> S: Time request
> The time request again includes C_pub (or H(C_pub)) and a 128 bit nonce
> C <- S: Time response
> The server calculates C_cookie (using C_pub) and uses it to append a
> MAC to the time response (which again includes the client's nonce)
> MAC = HMAC(C_cookie, time_response)
> The hash function H in this case should be at least sha2.
> Note that the nonce in the time requests/responses is not in the current
> draft yet.
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography