Hi,
I was wondering what most folks use for NTP security?
Do they use the low cost, light weight symmetric key cryptographic
protection method using MD5 or do folks go in for full digital
signatures and X.509 certificates (AutoKey Security)?
Thanks,
Glen
I'm just wondering -- in globak scheme of security issue, is NTP
security a major issue?
Just curious.
- ferg
Out of sync time was a big deal in James Bond 18 (Tomorrow Never Dies).
Anyway, pushing time out of sync seems an interesting way to break services that require stuff to be synced up. Kerberos is one such example.
Push a KDC out of sync from it's clients, and auth wouldn't happen anymore. Seems like a simple way to kick router admins out of their equipment if you're causing trouble, or at least, slow them down.
Of course, this only really works if your network has 3 reliable+secure time sources + 1 for redundancy. I'm not sure that .*pool\.ntp\.org would class as reliable+secure if you're concerned about NTP security.
The analytical/forensic fidelity of various forms of telemetry such as NetFlow, syslog, etc. is highly dependent upon an accurate time-hack, as well.
The biggest problem is that you pretty much have to spoof a server that
the client is already configured to be accepting NTP packets from. And *then* you have to
remember that your packets can only lie about the time by a very small number
of milliseconds or they get tossed out by the NTP packet filter that measures
the apparent jitter. Remember, the *real* clock is also sending correct
updates. At *best*, you lie like hell, and get the clock thrown out as
an "insane" timesource. But at that point, a properly configured clock
will go on autopilot till a quorum of sane clocks reappears, so you don't
have much chance of wedging in a huge time slew (unless you *really* hit
the jackpot, and the client reboots and does an ntpdate and you manage to
cram in enough false packets to mis-set the clock then).
So in most cases, you can only push the clock around by milliseconds - and
that doesn't buy you very much room for a replay attack or similar, because
that's under the retransmit timeout for a lost packet. It isn't like you
can get away with replaying something from 5 minutes ago.
Now, if you wanted to be *dastardly*, you'd figure out where a site's
Stratum-1 server(s) have their GPS antennas, and you'd read the recent
research on spoofing GPS signals - at *that* point you'd have a good chance
of controlling the horizontal and vertical....
I dont think this is correct.
I have seen routing protocol adjacencies going down because of some
perturbations in NTP. I understand, any router implementation worth
its salt would not use the NTP clock internally, but i have seen some
real life issues where OSPF went down because the time moved ahead and
it thought that it hadnt heard from the neighbor since a long time.
All such bugs were eventually fixed, but this is just one example.
There is an emerging need to distribute highly accurate time
information over IP and over MPLS packet switched networks (PSNs). A
variety of applications require time information to a precision which
existing protocols cannot supply. TICTOC is an IETF WG created to
develop solutions that meet the requirements of such protocols and
applications.
Glen
There is an emerging need to distribute highly accurate time
information over IP and over MPLS packet switched networks (PSNs).
good of you to ask. it exists today.
http://ieee1588.nist.gov/
cheers,
lincoln.
http://nob.cs.ucdavis.edu/bishop/papers/1990-acsac/ is old but does
have a good analysis of the problem.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
depends on your POV... in a dns context, TSIG and DNSSEC validation
depend on accurate time - failure to resolve data because of a time slip
might be considered a significantissue.
--bill
My original question got drowned amidst all this vibrant discussions!
Do folks already use or plan to use Autokey for NTP?
Glen
According to the TICTOC charter, you need more than just IEEE 1588
for accurate time distribution over IP and/or MPLS networks.
http://www.ietf.org/html.charters/tictoc-charter.html
Tony.
Of course, this only really works if your network has 3 reliable
+secure time sources + 1 for redundancy. I'm not sure that .*pool\.ntp
\.org would class as reliable+secure if you're concerned about NTP
security.
It's important to recognize that "secure" NTP has nothing to do with real
World time, and everything to do with all your secure systems being on
*the same* time, whatever that is. It really doesn't matter (much) if your
secure NTP cluster gets its time from an inconsistent source [provided it won't
allow changes of too great a magnitude at a time] but as long as they are all on the *same* time, you can maintain your security.
From an SPs point-of-view, security is very odd. It doesn't matter how well your
"internal" systems are if you are sending mail with the wrong time (say some
future date) and MTAs at your customers are rejecting them.
Deepak
Just a shame the world is not built on Ethernets. IETF tried to do TICTOC which will/could have done a better time-transfer over any IP network. But...let's see...
Best regards,
- - kurtis -
Maybe not NTP per se but timing is.
Best regards,
- - kurtis -
In my experience most people have a hard enough time remembering to run ntp at all (and with an even remotely sane configuration - this is why a sane default using the ntp pool is helpful as a baseline). Add authentication into the mix and many operations will almost certainly just have even more mis-configuration. 
- ask