NTP Cryptographic Authentication (Autokey)

1
NTP Cryptographic Authentication (Autokey)

• David L. Mills
• University of Delaware
• http//www.eecis.udel.edu/mills
• mailtomills_at_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
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

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 gt 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
U
A
W
V
B
C
X
D
Y
Z
E
F
Group Denise
Group Alice

• 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.

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)
Strat
Poll
LI
Mode
VN
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
Message Digest (128)
MAC
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/sta
  tus.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