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 timeserver).
Exactly how untrusted is the server assumed to be? 2013/9/1 Stephen Röttger <stephen.roett...@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: > 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
