4 ms·

ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for

by dfc 12y ago

ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or PTP to acquire and synch to UTC. Why would anyone need encrypted time synch? I do not understand the privacy implications, UTC is not a secret. [1]: For example: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm or https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio... [2]: My sure gps puck cost $40. It works with the antenna sitting on the window ledge inside my house.

FireBeyond 12y ago
You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don't require millisecond level time sync...)
- dfc 12y ago
  You are confusing authentication and encryption. Authenticated time protects against MITM attacks. You can obtain authenticated time synch from many national labs, such as NIST[1] or CRC[2]. I do not understand the need for confidentiality. [1]: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm [2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...
  - FireBeyond 12y ago
    Well, my thought was that you might be able to determine local clock drift by snooping. But as then mentioned, that's of near zero use, I suspect (as anything that uses time sync for authentication or otherwise is not likely to be that tightly bound to accuracy).
hannob 12y ago
ntp authentication is broken: http://zero-entropy.de/autokey_analysis.pdf http://zero-entropy.de/autokey_analysis.pdf and it was the same guy who found the new vulnerabilities :-)
- dfc 12y ago
  In order for the attack to succeed Eve needs to be able to MITM every configured ntp server association and do so before the daemon starts up. FYI Stephen Röttger is also the same guy who is a co-author of the two IETF proposals for the successor to autokey; Network Time Security[1] and Crypto Message Syntax for NTS[2]. [1]: https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-04 https://tools.ietf.org/html/draft-ietf-ntp-network-time-secu... [2]: https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-message-00 https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-messa...
Taek 12y ago
Encrypted might not be necessary but you want to be sure your computer is getting the right time. An out of sync Bitcoin miner for example will only produce invalid blocks. Tor I believe also relies on an accurate clock. Bitcoin relies on more than NTP so it's not a huge vulnerability, but NTP's vulnerability is a headache to many security developers.

by dfc 12y ago

FireBeyond 12y ago

You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don't require millisecond level time sync...)

dfc 12y ago
You are confusing authentication and encryption. Authenticated time protects against MITM attacks. You can obtain authenticated time synch from many national labs, such as NIST[1] or CRC[2]. I do not understand the need for confidentiality. [1]: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm [2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...
- FireBeyond 12y ago
  Well, my thought was that you might be able to determine local clock drift by snooping. But as then mentioned, that's of near zero use, I suspect (as anything that uses time sync for authentication or otherwise is not likely to be that tightly bound to accuracy).

hannob 12y ago

ntp authentication is broken: http://zero-entropy.de/autokey_analysis.pdf http://zero-entropy.de/autokey_analysis.pdf and it was the same guy who found the new vulnerabilities :-)

dfc 12y ago
In order for the attack to succeed Eve needs to be able to MITM every configured ntp server association and do so before the daemon starts up. FYI Stephen Röttger is also the same guy who is a co-author of the two IETF proposals for the successor to autokey; Network Time Security[1] and Crypto Message Syntax for NTS[2]. [1]: https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-04 https://tools.ietf.org/html/draft-ietf-ntp-network-time-secu... [2]: https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-message-00 https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-messa...

Taek 12y ago

Encrypted might not be necessary but you want to be sure your computer is getting the right time. An out of sync Bitcoin miner for example will only produce invalid blocks. Tor I believe also relies on an accurate clock. Bitcoin relies on more than NTP so it's not a huge vulnerability, but NTP's vulnerability is a headache to many security developers.