1. NTP Cryptographic Authentication (Autokey)
David L. Mills
University of Delaware
27-Nov-18

2. Briefing roadmap on NTP technology and performance
NTP project page
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
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

7. NTP host client and server model
Peer 1
Filter 1
Intersection
and
Clustering
Algorithms
Combining
Algorithm
Peer 2
Filter 2
Loop Filter
P/F-Lock Loop
Peer 3
Filter 3
VFO
NTP Messages
Timestamps
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
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

10. NTP secure group configuration exampleB C D V W X E F Y Z
Group Alice
Group Denise
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.
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

13. NTP packet formats Unprotected packets include only the NTP header.
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
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

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.
27-Nov-18

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
27-Nov-18

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
27-Nov-18

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:
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
27-Nov-18

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
27-Nov-18

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
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
Current research project descriptions and briefings
27-Nov-18