Have you considered merkle trees for scalability? Specifically a client can generate a unique 128-bit nonce and have the trusted server timestamp it by signing a message including the nonce and the current time T. If the time between the request and the reply was dt, the actual time must be in the range (T, dt)
We can then extend this to an arbitrary number of clients with a merkle tree and one or more levels of untrusted servers. The servers combine all the nonces they receive in some time interval t into a merkle tree, then timestamp the digest of the tip of that tree. The clients then receive the merkle paths from the server, a proof of log2(n) size. If a client doesn't trust the server at all, they know the time is within (T, dt); if they are willing to place some trust in the server the server can measure the interval between when they got the request and sent the proof, dt', and the client can take that into account for a more precise time. Of course there are advantages and disadvantages to all these methods, but the above is particularly good for the majority of clients like desktops setting their clocks automatically that probably just need the time accurate to within a second or two. Eg the ntp.ubuntu.com servers and similar ones. Reducing the number of timestamping servers that need to be trusted with private keys is a very good thing. What you described below is I think compatible with the above - I'm on vacation and didnt look too closely - but it'd be good to ensure that the way to do so efficient and obvious. On 2013-09-01, at 10:45, "Stephen Röttger" <stephen.roett...@gmail.com> wrote: > 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: > http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00 > > And the previous discussion on the mailing list of the working group: > http://lists.ntp.org/pipermail/ntpwg/2013-July/001886.html > http://lists.ntp.org/pipermail/ntpwg/2013-August/001899.html > > 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. > > Regards, > Stephen > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
