NTP Cryptographic Authentication (Autokey)

1. NTP Cryptographic Authentication (Autokey) David L. Mills University of Delaware http://www.eecis.udel.edu/~mills mailto:mills@udel.edu

2. Briefing roadmap on NTP technology and performance • NTP project page http://www.eecis.udel.edu/~mills/ntp.html/. • Network Time Protocol (NTP) General Overview • NTP Architecture, Protocol and Algorithms • NTP Procedure Descriptions and Flow Diagrams • NTP Cryptographic Authentication (Autokey) • NTP Clock Discipline Principles • NTP Precision Synchronization • NTP Performance Analysis • NTP Algorithm Analysis • Long-range Dependency Effects in NTP Timekeeping

3. NTP security model • NTP operates in a mixed, multi-level security environment including symmetric key cryptography, public key cryptography and unsecured. • NTP timestamps and related data are considered public values and never encrypted. • Time synchronization is maintained on a master-slave basis where synchronization flows from trusted servers to dependent clients possibly via intermediate servers operating at successively higher stratum levels. • A client is authentic if it can reliably verify the credentials of at least one server and that server messages have not been modified in transit. • A client is proventic if by induction each server on at least one path to a trusted server is authentic.

4. Intruder attacks • An intruder can intercept and archive packets forever, as well as all the public values ever generated and transmitted over the net. • An intruder can generate packets faster than the server, network or client can process them, especially if they require expensive cryptographic computations. • In a wiretap attack the intruder can intercept, modify and replay a packet. However, it cannot permanently prevent onward transmission of the original packet; that is, it cannot break the wire, only tell lies and congest it. It is generally assumed that the modified packet cannot arrive at the victim before the original packet. • In a middleman or masquerade attack the intruder is positioned between the server and client, so it can intercept, modify and replay a packet and prevent onward transmission of the original packet. It is generally assumed that the middleman does not have the server private keys or identity parameters.

5. Security requirements • The running times for public key algorithms are relatively long and highly variable, so that the synchronization function itself must not require their use for every NTP packet. • In some modes of operation it is not feasible for a server to retain state variables for every client. It is however feasible to regenerated them for a client upon arrival of a packet from that client. • The lifetime of cryptographic values must be enforced, which requires a reliable system clock. However, the sources that synchronize the system clock must be cryptographically proventicated. This circular interdependence of the timekeeping and proventication functions requires special handling.

6. Security requirements (continued) • All proventication functions must involve only public values transmitted over the net with the single exception of encrypted signatures and cookies intended only to authenticate the source. Unencrypted private values must never be disclosed beyond the machine on which they were created. • Public encryption keys and certificates must be retrievable directly from servers without requiring secured channels; however, the fundamental security of identification credentials and public values bound to those credentials must be a function of certificate authorities and/or webs of trust. • Error checking must be at the enhanced paranoid level, as network terrorists may be able to craft errored packets that consume excessive cycles with needless result.

7. NTP host client and server model Peer 1 Filter 1 Intersection and Clustering Algorithms • Anatomy of a NTP host • Multiple servers/peers provide redundancy and diversity • Clock filters select best from a window of offset/delay samples • Intersection algorithm discards falsetickers using Byzantine agreement • Clustering algorithm picks the best subset of peers • Combining algorithm, loop filter and variable frequency oscillator (VFO) implement hybrid phase/frequency-lock feedback loop which determines the system time Combining Algorithm Peer 2 Filter 2 Loop Filter P/F-Lock Loop Peer 3 Filter 3 VFO NTP Messages Timestamps

8. NTP subnet principles • The NTP network is a forest of hosts operating as servers and clients • Primary (stratum 1) servers are the forest roots. • Secondary (stratum > 1) servers join the trunks and branches of the forest. • Clients are secondary servers at the leaves of the forest. • Secondary servers normally use multiple redundant servers and diverse network paths to the same or next lower stratum level toward the roots. • An NTP subnet is a subset of the NTP network. • Usually, but not necessarily, the subnet is operated by a single management entity over local networks belonging to the entity. • The set of lowest-stratum hosts represent the roots of the subnet. • The remaining subnet hosts must have at least one path to at least one of the roots. • The NTP subnet is self contained if the roots are all primary (stratum 1) servers and derivative if not. • Subnets may include branches to other subnets for primary and backup service and to create hierarchical multi-subnet structures.

9. NTP secure group principles • A secure group is a NTP subnet using a common identity scheme based on symmetric key cryptography or public key cryptography. • Each group host has • A password-encrypted common group key generated by a trusted host. • For public key cryptography a public/private host key pair and self-signed certificate, • Each group has a single trusted host which in addition • Operates at the lowest stratum of the group. • Generated the current group key. • For public key cryptography a trusted, self-signed certificate. • A host can belong to more than one group. • The above rules apply for each group separately. • If the NTP subnet contains more than one server at the lowest stratum, each server will be trusted and in a different group.

10. NTP secure group configuration example • There are two groups, Alice and Denise with individual group keys. • Alice has trusted host A which generates her group key and Denise has trusted host U which generates her group key. • Hosts D and V have both group keys, but not the other hosts in either group. • The Autokey protocol authenticates the Alice group key via a certificate trail to A and the Denise group key via a certificate trail through V to U. U A V W B C X D Y Z E F Group Denise Group Alice

11. Security protocol requirements • It must interoperate with the existing NTP architecture model and protocol design. In particular, it must support the symmetric key scheme described in RFC-1305. • It must provide for the independent collection of cryptographic values and time values. A NTP packet is accepted for processing only when the required cryptographic values have been obtained and verified and the NTP header has passed all sanity checks. • It must not significantly degrade the potential accuracy of the NTP synchronization algorithms. In particular, it must not make unreasonable demands on the network or host processor and memory resources. • It must be resistant to cryptographic attacks, specifically those identified in the security model above. In particular, it must be tolerant of operational or implementation variances, such as packet loss or misorder, or suboptimal configurations.

12. Security protocol requirements (continued) • It must build on a widely available suite of cryptographic algorithms, yet be independent of the particular choice. In particular, it must not require data encryption other than incidental to signature and cookie encryption operations. • It must function in all the modes supported by NTP, including server, symmetric and broadcast modes. • It must not require intricate per-client or per-server configuration other than the availability of the required cryptographic keys and certificates. • The reference implementation must contain provisions to generate cryptographic key files specific to each client and server.

13. NTP packet formats NTP Protocol Header Format (32 bits) LI VN Mode Strat Poll Prec Root Delay • Unprotected packets include only the NTP header. • Symmetric key packets include the MAC. • The MAC is computed on the NTP header and extension fields. • Public key packets include the MAC and extension fields. Root Dispersion Reference Identifier Reference Timestamp (64) NTP Header Originate Timestamp (64) Receive Timestamp (64) Transmit Timestamp (64) Extension Field 1 (optional) Extension Fields Extension Field 2… (optional) Key/Algorithm Identifier NTP v3 and v4 MAC Message Digest (128) NTP v4 only authentication only

14. NTP symmetric key cryptography • NTP symmetric key cryptography is based on keyed MD5 message digests. • A message authentication code (MAC) is computed as the MD5 digest of the message concatenated with the group key. • The computed MAC follows the message in the transmitted packet. • The receiver computes the MAC in the same way and verifies it matches the MAC in the packet. • The group key consists of a 32-bit key ID and a 128-bit MD5 key. • Each group has a different key distinguished by the key ID included in the MAC. • Keys are created by the group trusted host and distributed by secure means. • Keys have indefinite lifetime, but can be activated and deactivated by configuration or remotely.

15. NTP public key cryptography • NTP public key cryptography is based on the Internet security infrastructure and Public Key Infrastructure (PKI) principles. • Each group host generates a RSA or DSA public/private key pair and self-signed X509v3 certificate. • The trusted group host certificate is explicitly designated as trusted using a X509v3 extension field. • A certificate trail is established dynamically where a client convinces the next lower stratum server to sign its certificate, which is then available to its own dependent clients. • A special purpose security protocol called Autokey verifies and instantiates cryptographic values as required. • At initialization Autokey recursively obtains certificates until terminating with the trusted certificate which authenticates the path. • In order to protect against middleman attacks, an optional cryptographic identity scheme can be used.

16. Identity schemes • Private certificate (PC) scheme • The trusted host generates a certificate marked private and transmits it by secure means to all group members. The certificate is never divulged to clients or servers and never presented for signature. • Trusted certificate (TC) scheme (default) • The certificate trail is validated to a self signed certificate marked trusted. The identity exchange is not used. This scheme is vulnerable to a middleman masquerade. • Schnorr (IFF) scheme • A trusted agent generates the IFF parameters and transmits them by secure means to all group members. The IFF identity exchange is used to verify identity. • Guillou-Quisquater (GQ) scheme • A trusted agent generates the GQ parameters and transmits them by secure means to all group members. Each member generates a GQ private/public key pair and certificates with the public key in an extension field. The GQ identity exchange is used to verify identity.

17. Current progress and status • NTP Version 4 architecture and algorithms • Backwards compatible with earlier versions • Improved local clock model implemented and tested • Multicast mode with propagation calibration implemented and tested • Distributed multicast mode protocol implemented and tested • Autonomous configuration autoconfigure • Span-limited add/drop heuristic metric implemented and in test • Static stratum assignment hierarchy implemented and in test • Autonomous authentication autokey • Completed integration with OpenSSL cryptographic library • Version 2 implemented in NTP Version 4 and tested • Automatic certificate trail search design in study

18. Future plans • Complete autoconfigure and autokey implementation in NTP Version 4 • Complete and test dynamic certificate validation in Autokey • Design, implement and test dynamic stratum assignment in Manycast • Complete IP Version 6 integration in NTP Version 4 • Deploy, test and evaluate NTP Version 4 in CAIRN testbed, then at friendly sites in the US, Europe and Asia • Revise the NTP formal specification and launch on standards track • Participate in deployment strategies with NIST, USNO, others • Prosecute standards agenda in IETF, ANSI, ITU, POSIX • Develop scenarios for other applications such as web caching, DNS servers and other multicast services

19. Further information • Network Time Protocol (NTP): http://www.ntp.org/ • Current NTP Version 3 and 4 software and documentation • FAQ and links to other sources and interesting places • David L. Mills: http://www.eecis.udel.edu/~mills • Papers, reports and memoranda in PostScript and PDF formats • Briefings in HTML, PostScript, PowerPoint and PDF formats • Collaboration resources hardware, software and documentation • Songs, photo galleries and after-dinner speech scripts • FTP server ftp.udel.edu (pub/ntp directory) • Current NTP Version 3 and 4 software and documentation repository • Collaboration resources repository • Related project descriptions and briefings • See “Current Research Project Descriptions and Briefings” at http://www.eecis.udel.edu/~mills/status.htm

20. NTP online resources at www.ntp.org • Network Time Protocol (NTP) Version 3 Specification RFC-1305 • NTPv4 features documented in release notes and reports cited elsewhere • Simple NTP (SNTP) Version 4 specification RFC-2030 • Applicable to IPv4, IPv6 and ISO CNLS • List of public NTP time servers (as of July 2004) • 128 active primary (stratum 1) servers • 178 active stratum 2 servers • NTP Version 4 software and documentation • Ported to over two dozen architectures and operating systems • Utility programs for remote monitoring, control and performance evaluation • Complete documentation in HTML format • NTP project page • Briefings, web pages, technical information

21. Further information • NTP home page http://www.ntp.org • Current NTP Version 3 and 4 software and documentation • FAQ and links to other sources and interesting places • David L. Mills home page http://www.eecis.udel.edu/~mills • Papers, reports and memoranda in PostScript and PDF formats • Briefings in HTML, PostScript, PowerPoint and PDF formats • Collaboration resources hardware, software and documentation • Songs, photo galleries and after-dinner speech scripts • Udel FTP server: ftp://ftp.udel.edu/pub/ntp • Current NTP Version software, documentation and support • Collaboration resources and junkbox • Related projects http://www.eecis.udel.edu/~mills/status.htm • Current research project descriptions and briefings