Názory k článku
Šifrovaný protokol NTS pro synchronizaci času

První otázka, která mě napadá, zda je zrovna tohle potřeba šifrovat. Napadá někoho, jak zneužít informace z NTPprotokolu? Na první pohled se mi zdá, že toto je nadbytečné využití výpočetního výkonu.

Spis bych rek, ze jde o prevenci proti MITM utoku a aby vam ten cas nikdo mezi vami a NTP serverem neupravil.

pokud se rozjede tak, že již máš nevalidní certifikát, stejně jsi udělal něco špatně. DNSSEC potřebuje mít skoro přesný čas na obou stranách, SSL/TLS v protokolu nikoliv a čas kontroluje jen vyšší vrstva.

Ano, občas server startujeme desítky minut, takže ten čas je odstřelený někdy dost.

Nešlo by třeba podvrhnout špatný čas?

Na aktualnim case napriklad zavisi platnost certifikatu...

Útoky existují a souvisejí právě s časovými údaji. Například je možné přivést uměle k životu revokované certifikáty s uniklými klíči, odemknout zablokovaný uživatelský účet, zapisovat špatné údaje do logů, ovlivnit opakovaně časově závislé akce (třeba tím vypnout zálohování), vyřadit z provozu resolver kvůli neplatným DNSSEC záznamům a podobně. Prostě nechcete, aby vám někdo manipuloval s časem.

Tak zabezpečení proti manipulaci už bylo v původním NTP protokolu. Pravda - autokey se nepovedl, neměl by se používat, dá se prolomit. U symetrického podepisování je to už OK, ale distribuce podepisovacích klíčů je problém (který né moc dobře řešil ten autokey). Jíná věc je, pokud by blyo potřeba utajit nějaké option údaje, tam součansé NTP nemá řešení.
Ale řešení s klasickým TLS nad TCP - jsem zvědav, jak se toto dostane do HW časových serverů (a to mám na mysli ty, kde je nyní celé NTP realizováno v hradlovém poli a ne v embedded linuxu). Nu, u NTS se dost angažoval třeba i Meinberg, tak třeba překvapí (i když se dívám, že ani současné HPS karty neumí u NTP podepisování). :-)

Součástí RFC8915 je také ochrana před zesilovacím útokem – aby odpověď serveru nebyla větší, než požadavek. Myslím, že těch věcí, které stojí za to v NTP řešit, se sešlo víc, tak dává smysl vydat nové RFC. A pokud jde o ochranu integrity a ochranu proti opakování – radši použít TLS, které je ověřené a mnohokrát zkontrolované, než vymýšlet něco nového.

U NTP je důležitá především integrita a ochrana proti opakování – potřebujete dostat správný čas. Utajení může být vhodné pro rozšiřující položky, které mohou být v NTP také přítomné.

Nebude mít zpoždění při provádění šifrování a dešifrování vliv na přesnost synchronizace?

NTP je postaven tak, aby opakovane spozdeni bylo eliminovano - prece do internetu taky nemate pristup bez zpozdeni, a to je o nekolik radu vetsi nez doba sifrovani malych paketu.

Hm, tak jsem si prošel jak NTS funguje a je tu rozpor s tím, co je ve zprávičce.
Čas se posílá pořád dál na UDP/123 a ve formátu, jak je v NTPv4 zvykem, aktuálně není ani šifrována časová informace (do budoucna se s tím počítá), jen za klasický NTP protokol se přidávají NTS bloky, které zabezpečují NTPv4 úvodní data.
Zjednodušeně: jde v podstatě o vylepšenou variantu sučasného symetrického podepisování (s odstraněním problémů autokey), kdy se příslušný "symetrický klíč" vyjedná prvně přes TLS spojení. TLS spojení na TCP/4460 (NTS-KE server) se použije pro získání tokenu/cookies, které se následně používají pro podepsání/zaši­frování NTP žádosti/odpovědi. Výměna dalších tokenů už probíhá uvnitř UDP/123 v EF blocích za NTP protokolem a dokud se udrží výměn dat nad UDP/123, tak nepotřebuji znovu kontaktovat NTS-KE server pro novou sadu cookies.

RFC8915: "This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the
client-server mode of the Network Time Protocol (NTP)."

NTS neni porotokol, ale mechanismus sifrovani pro NTPv4 protokol.