Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-12

encrypted), within it (therefore encrypted and authenticated), or
   after it (therefore neither encrypted nor authenticated).  In
   general, however, the client MUST discard any unauthenticated
   extension fields and process the packet as though they were not
   present.  Clients MAY implement exceptions to this requirement for
   particular extension fields if their specification explicitly
   provides for such.

   If the server is unable to validate the cookie or authenticate the
   request, it SHOULD respond with a Kiss-o'-Death packet (see RFC 5905,
   Section 7.4) [RFC5905]) with kiss code "NTSN" (meaning "NTS NAK").
   Such a response MUST include exactly one Unique Identifier extension
   field whose contents SHALL echo those provided by the client.  It
   MUST NOT include any NTS Cookie or NTS Authenticator and Encrypted
   Extension Fields extension fields.

   Upon receiving an NTS-protected response, the client MUST verify that
   the Unique Identifier matches that of an outstanding request, and
   that the packet is authentic under the S2C key associated with that
   request.  If either of these checks fails, the packet MUST be
   discarded without further processing.

   Upon receiving an NTS NAK, the client MUST verify that the Unique
   Identifier matches that of an outstanding request.  If this check
   fails, the packet MUST be discarded without further processing.  If
   this check passes, the client SHOULD wait until the next poll for a
   valid NTS-protected response and if none is received, discard all
   cookies and AEAD keys associated with the server which sent the NAK
   and initiate a fresh NTS-KE handshake.

Franke, et al.           Expires January 2, 2019               [Page 17]
Internet-Draft                   NTS4NTP                       July 2018

                   +---------------------------------------+
                   | - verify time request message         |
                   | - generate time response message      |
                   |   - included NTPv4 extension fields   |
                   |      o Unique Identifier EF           |
                   |      o NTS Authentication and         |
                   |        Encrypted Extension Fields EF  |
                   |        - NTS Cookie EF                |
                   |        - <NTS Cookie EF>              |
                   | - transmit time request packet        |
                   +-----------------+---------------------+
                                     |
                                     |
   Server -------- --+---------------+-----+----------------------->
                     ^                      \
                    /                        \
     time request  /                          \   time response
     (mode 3)     /                            \  (mode 4)
                 /                              \
                /                                V
   Client -----+---------------------------------+---------------->
               |                                 |
               |                                 |
               |                                 |
   +-----------+----------------------+   +------+-----------------+
   |- generate time request message   |   |- verify time response  |
   | - include NTPv4 Extension fields |   |  message               |
   |    o Unique Identifier EF        |   |- extract cookie(s)     |
   |    o NTS Cookie EF               |   |- time synchronization  |
   |    o <NTS Cookie Placeholder EF> |   |  processing            |
   |                                  |   +------------------------+
   |- generate AEAD tag of NTP message|
   |- add NTS Authentication and      |
   |  Encrypted Extension Fields EF   |
   |- transmit time request packet    |
   +----------------------------------+

                Figure 3: NTS Time Synchronization Message

7.  Suggested format for NTS cookies

   This section is non-normative.  It gives a suggested way for servers
   to construct NTS cookies.  All normative requirements are stated in
   Section 4.1.6 and Section 5.4.

   The role of cookies in NTS is closely analogous to that of session
   cookies in TLS.  Accordingly, the thematic resemblance of this

Franke, et al.           Expires January 2, 2019               [Page 18]
Internet-Draft                   NTS4NTP                       July 2018

   section to RFC 5077 [RFC5077] is deliberate, and the reader should
   likewise take heed of its security considerations.

   Servers should select an AEAD algorithm which they will use to
   encrypt and authenticate cookies.  The chosen algorithm should be one
   such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental
   nonce reuse, and it need not be the same as the one that was
   negotiated with the client.  Servers should randomly generate and
   store a master AEAD key `K`. Servers should additionally choose a
   non-secret, unique value `I` as key-identifier for `K`.

   Servers should periodically (e.g., once daily) generate a new pair
   (I,K) and immediately switch to using these values for all newly-
   generated cookies.  Immediately following each such key rotation,
   servers should securely erase any keys generated two or more rotation
   periods prior.  Servers should continue to accept any cookie
   generated using keys that they have not yet erased, even if those
   keys are no longer current.  Erasing old keys provides for forward
   secrecy, limiting the scope of what old information can be stolen if
   a master key is somehow compromised.  Holding on to a limited number
   of old keys allows clients to seamlessly transition from one
   generation to the next without having to perform a new NTS-KE
   handshake.

   The need to keep keys synchronized across load-balanced clusters can
   make automatic key rotation challenging.  However, the task can be
   accomplished without the need for central key-management
   infrastructure by using a ratchet, i.e., making each new key a
   deterministic, cryptographically pseudo-random function of its
   predecessor.  A recommended concrete implementation of this approach
   is to use HKDF [RFC5869] to derive new keys, using the key's
   predecessor as Input Keying Material and its key identifier as a
   salt.

   To form a cookie, servers should first form a plaintext `P`
   consisting of the following fields:

      The AEAD algorithm negotiated during NTS-KE

      The S2C key

      The C2S key

   Servers should then generate a nonce `N` uniformly at random, and
   form AEAD output `C` by encrypting `P` under key `K` with nonce `N`
   and no associated data.

   The cookie should consist of the tuple `(I,N,C)`.

Franke, et al.           Expires January 2, 2019               [Page 19]
Internet-Draft                   NTS4NTP                       July 2018

   To verify and decrypt a cookie provided by the client, first parse it
   into its components `I`, `N`, and `C`. Use `I` to look up its
   decryption key `K`. If the key whose identifier is `I` has been
   erased or never existed, decryption fails; reply with an NTS NAK.
   Otherwise, attempt to decrypt and verify ciphertext `C` using key `K`
   and nonce `N` with no associated data.  If decryption or verification
   fails, reply with an NTS NAK.  Otherwise, parse out the contents of
   the resulting plaintext `P` to obtain the negotiated AEAD algorithm,
   S2C key, and C2S key.

8.  IANA Considerations

   IANA is requested to allocate two entries, identical except for the
   Transport Protocol, in the Service Name and Transport Protocol Port
   Number Registry as follows:

      Service Name: nts

      Transport Protocol: tcp, udp

      Assignee: IESG <iesg@ietf.org>

      Contact: IETF Chair <chair@ietf.org>

      Description: Network Time Security

      Reference: [[this memo]]

      Port Number: [[TBD1]], selected by IANA from the user port range

   IANA is requested to allocate the following entry in the Application-
   Layer Protocol Negotation (ALPN) Protocol IDs registry:

      Protocol: Network Time Security Key Establishment, version 1

      Identification Sequence:
      0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")

      Reference: [[this memo]]

   IANA is requested to allocate the following entry in the TLS Exporter
   Label Registry:

   +----------------------------------+---------+---------------+------+
   | Value                            | DTLS-OK | Reference     | Note |
   +----------------------------------+---------+---------------+------+
   | EXPORTER-network-time-security/1 | Y       | [[this memo]] |      |
   +----------------------------------+---------+---------------+------+

Franke, et al.           Expires January 2, 2019               [Page 20]
Internet-Draft                   NTS4NTP                       July 2018

   IANA is requested to allocate the following entry in the registry of
   NTP Kiss-o'-Death codes:

                            +------+---------+
                            | Code | Meaning |
                            +------+---------+
                            | NTSN | NTS NAK |
                            +------+---------+

   IANA is requested to allocate the following entries in the NTP
   Extensions Field Types registry:

   +-----------+-----------------------------------------+-------------+
   | Field     | Meaning                                 | Reference   |
   | Type      |                                         |             |
   +-----------+-----------------------------------------+-------------+
   | [[TBD2]]  | Unique Identifier                       | [[this      |
   |           |                                         | memo]]      |
   | [[TBD3]]  | NTS Cookie                              | [[this      |
   |           |                                         | memo]]      |
   | [[TBD4]]  | NTS Cookie Placeholder                  | [[this      |
   |           |                                         | memo]]      |
   | [[TBD5]]  | NTS Authenticator and Encrypted         | [[this      |
   |           | Extension Fields                        | memo]]      |
   +-----------+-----------------------------------------+-------------+

   IANA is requested to create a new registry entitled "Network Time
   Security Key Establishment Record Types".  Entries SHALL have the
   following fields:

      Type Number (REQUIRED): An integer in the range 0-32767 inclusive.

      Description (REQUIRED): A short text description of the purpose of
      the field.

      Set Critical Bit (REQUIRED): One of "MUST", "SHOULD", "MAY",
      "SHOULD NOT", or "MUST NOT".

      Reference (REQUIRED): A reference to a document specifying the
      semantics of the record.

   The policy for allocation of new entries in this registry SHALL vary
   by the Type Number, as follows:

      0-1023: IETF Review

      1024-16383: Specification Required

Franke, et al.           Expires January 2, 2019               [Page 21]
Internet-Draft                   NTS4NTP                       July 2018

      16384-32767: Private and Experimental Use

   Applications for new entries SHALL specify the contents of the
   Description, Set Critical Bit and Reference fields and which of the
   above ranges the Type Number should be allocated from.  Applicants
   MAY request a specific Type Number, and such requests MAY be granted
   at the registrar's discretion.

   The initial contents of this registry SHALL be as follows:

   +-------------+-----------------------------+----------+------------+
   | Field       | Description                 | Critical | Reference  |
   | Number      |                             |          |            |
   +-------------+-----------------------------+----------+------------+
   | 0           | End of message              | MUST     | [[this     |
   |             |                             |          | memo]]     |
   | 1           | NTS next protocol           | MUST     | [[this     |
   |             | negotiation                 |          | memo]]     |
   | 2           | Error                       | MUST     | [[this     |
   |             |                             |          | memo]]     |
   | 3           | Warning                     | MUST     | [[this     |
   |             |                             |          | memo]]     |
   | 4           | AEAD algorithm negotiation  | MAY      | [[this     |
   |             |                             |          | memo]]     |
   | 5           | New cookie for NTPv4        | SHOULD   | [[this     |
   |             |                             | NOT      | memo]]     |
   | 16384-32767 | Reserved for Private &      | MAY      | [[this     |
   |             | Experimental Use            |          | memo]]     |
   +-------------+-----------------------------+----------+------------+

   IANA is requested to create a new registry entitled "Network Time
   Security Next Protocols".  Entries SHALL have the following fields:

      Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive,
      functioning as an identifier.

      Protocol Name (REQUIRED): A short text string naming the protocol
      being identified.

      Reference (RECOMMENDED): A reference to a relevant specification
      document.  If no relevant document exists, a point-of-contact for
      questions regarding the entry SHOULD be listed here in lieu.

   Applications for new entries in this registry SHALL specify all
   desired fields, and SHALL be granted upon approval by a Designated
   Expert.  Protocol IDs 32768-65535 SHALL be reserved for Private or
   Experimental Use, and SHALL NOT be registered.

Franke, et al.           Expires January 2, 2019               [Page 22]
Internet-Draft                   NTS4NTP                       July 2018

   The initial contents of this registry SHALL be as follows:

   +-------------+-------------------------------+---------------------+
   | Protocol ID | Human-Readable Name           | Reference           |
   +-------------+-------------------------------+---------------------+
   | 0           | Network Time Protocol version | [[this memo]]       |
   |             | 4 (NTPv4)                     |                     |
   | 32768-65535 | Reserved for Private or       | Reserved by [[this  |
   |             | Experimental Use              | memo]]              |
   +-------------+-------------------------------+---------------------+

   IANA is requested to create two new registries entitled "Network Time
   Security Error Codes" and "Network Time Security Warning Codes".
   Entries in each SHALL have the following fields:

      Number (REQUIRED): An integer in the range 0-65535 inclusive.

      Description (REQUIRED): A short text description of the condition.

      Reference (REQUIRED): A reference to a relevant specification
      document.

   The policy for allocation of new entries in these registries SHALL
   vary by their Number, as follows:

      0-1023: IETF Review

      1024-32767: Specification Required

      32768-65535: Private and Experimental Use

   The initial contents of the Network Time Security Error Codes
   Registry SHALL be as follows:

       +--------+---------------------------------+---------------+
       | Number | Description                     | Reference     |
       +--------+---------------------------------+---------------+
       | 0      | Unrecognized Critical Extension | [[this memo]] |
       | 1      | Bad Request                     | [[this memo]] |
       +--------+---------------------------------+---------------+

   The Network Time Security Warning Codes Registry SHALL initially be
   empty.

Franke, et al.           Expires January 2, 2019               [Page 23]
Internet-Draft                   NTS4NTP                       July 2018

9.  Implementation Status

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in RFC 7942.
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to RFC 7942, "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

9.1.  Implementation PoC 1

   Organization: Ostfalia University of Applied Science

   Implementor: Martin Langer

   Maturity: Proof-of-Concept Prototype

   This implementation was used to verify consistency and to ensure
   completeness of this specification.  It also demonstrate
   interoperability with NTP's client-server mode messages.

9.1.1.  Coverage

   This implementation covers the complete specification.

9.1.2.  Licensing

   The code is released under a Apache License 2.0 license.

   The source code is available at: https://gitlab.com/MLanger/nts/

Franke, et al.           Expires January 2, 2019               [Page 24]
Internet-Draft                   NTS4NTP                       July 2018

9.1.3.  Contact Information

   Contact Martin Langer: mart.langer@ostfalia.de

9.1.4.  Last Update

   The implementation was updated 3rd May 2018.

9.2.  Implementation PoC 2

   Organization: tbd

   Implementor: Daniel Fox Franke

   Maturity: Proof-of-Concept Prototype

   This implementation was used to verify consistency and to ensure
   completeness of this specification.

9.2.1.  Coverage

   This implementation provides the client and the server for the
   initial TLS handshake and NTS key exchange.  It provides the the
   client part of the NTS protected NTP messages.

9.2.2.  Licensing

   Public domain.

   The source code is available at: https://github.com/dfoxfranke/nts-
   hackathon

9.2.3.  Contact Information

   Contact Daniel Fox Franke: dfoxfranke@gmail.com

9.2.4.  Last Update

   The implementation was updated 16th March 2018.

9.3.  Interoperability

   The Interoperability tests distinguished between NTS key exchange and
   NTS time exchange messages.  For the NTS key exchange,
   interoperability between the two implementations has been verified
   successfully.  Interoperability of NTS time exchange messages has
   been verified successfully for the case that PoC 1 represents the
   server and PoC 2 the client.

Franke, et al.           Expires January 2, 2019               [Page 25]
Internet-Draft                   NTS4NTP                       July 2018

   These tests successfully demonstrate that there are at least two
   running implementations of this draft which are able to interoperate.

10.  Security considerations

10.1.  Avoiding DDoS amplification

   Certain non-standard and/or deprecated features of the Network Time
   Protocol enable clients to send a request to a server which causes
   the server to send a response much larger than the request.  Servers
   which enable these features can be abused in order to amplify traffic
   volume in distributed denial-of-service (DDoS) attacks by sending
   them a request with a spoofed source IP.  In recent years, attacks of
   this nature have become an endemic nuisance.

   NTS is designed to avoid contributing any further to this problem by
   ensuring that NTS-related extension fields included in server
   responses will be the same size as the NTS-related extension fields
   sent by the client.  In particular, this is why the client is
   required to send a separate and appropriately padded-out NTS Cookie
   Placeholder extension field for every cookie it wants to get back,
   rather than being permitted simply to specify a desired quantity.

   Due to the [RFC7822] requirement that extensions be padded and
   aligned to four-octet boundaries, response size may still in some
   cases exceed request size by up to three octets.  This is
   sufficiently inconsequential that we have declined to address it.

10.2.  Initial verification of server certificates

   NTS's security goals are undermined if the client fails to verify
   that the X.509 certificate chain presented by the server is valid and
   rooted in a trusted certificate authority.  [RFC5280] and [RFC6125]
   specify how such verification is to be performed in general.
   However, the expectation that the client does not yet have a
   correctly-set system clock at the time of certificate verification
   presents difficulties with verifying that the certificate is within
   its validity period, i.e., that the current time lies between the
   times specified in the certificate's notBefore and notAfter fields,
   and it may be operationally necessary in some cases for a client to
   accept a certificate which appears to be expired or not yet valid.
   While there is no perfect solution to this problem, there are several
   mitigations the client can implement to make it more difficult for an
   adversary to successfully present an expired certificate:

      Check whether the system time is in fact unreliable.  If the
      system clock has previously been synchronized since last boot,
      then on operating systems which implement a kernel-based phase-

Franke, et al.           Expires January 2, 2019               [Page 26]
Internet-Draft                   NTS4NTP                       July 2018

      locked-loop API, a call to ntp_gettime() should show a maximum
      error less than NTP_PHASE_MAX.  In this case, the clock SHOULD be
      considered reliable and certificates can be strictly validated.

      Allow the system administrator to specify that certificates should
      *always* be strictly validated.  Such a configuration is
      appropriate on systems which have a battery-backed clock and which
      can reasonably prompt the user to manually set an approximately-
      correct time if it appears to be needed.

      Once the clock has been synchronized, periodically write the
      current system time to persistent storage.  Do not accept any
      certificate whose notAfter field is earlier than the last recorded
      time.

      Do not process time packets from servers if the time computed from
      them falls outside the validity period of the server's
      certificate.

      Use multiple time sources.  The ability to pass off an expired
      certificate is only useful to an adversary who has compromised the
      corresponding private key.  If the adversary has compromised only
      a minority of servers, NTP's selection algorithm ([RFC5905]
      section 11.2.1) will protect the client from accepting bad time
      from the adversary-controlled servers.

10.3.  Usage of NTP pools

   Additional standardization work and infrastructure development is
   necessary before NTS can be used with public NTP server pools.
   First, a scheme will need to be specified for determining what
   constitutes an acceptable certificate for a pool server, such as
   establishing a value required to be contained in its Extended Key
   Usage attribute, and how to determine, given the DNS name of a pool,
   what Subject Alternative Name to expect in the certificates of its
   members.  Implementing any such specification will necessitate
   infrastructure work: pool organizers will need to act as certificate
   authorities, regularly monitor the behavior of servers to which
   certificates have been issued, and promptly revoke the certificate of
   any server found to be serving incorrect time.

10.4.  Delay attacks

   In a packet delay attack, an adversary with the ability to act as a
   man-in-the-middle delays time synchronization packets between client
   and server asymmetrically [RFC7384].  Since NTP's formula for
   computing time offset relies on the assumption that network latency
   is roughly symmetrical, this leads to the client to compute an

Franke, et al.           Expires January 2, 2019               [Page 27]
Internet-Draft                   NTS4NTP                       July 2018

   inaccurate value [Mizrahi].  The delay attack does not reorder or
   modify the content of the exchanged synchronization packets.
   Therefore, cryptographic means do not provide a feasible way to
   mitigate this attack.  However, the maximum error that an adversary
   can introduce is bounded by half of the round trip delay.

   [RFC5905] specifies a parameter called MAXDIST which denotes the
   maximum round-trip latency (including not only the immediate round
   trip between client and server but the whole distance back to the
   reference clock as reported in the Root Delay field) that a client
   will tolerate before concluding that the server is unsuitable for
   synchronization.  The standard value for MAXDIST is one second,
   although some implementations use larger values.  Whatever value a
   client chooses, the maximum error which can be introduced by a delay
   attack is MAXDIST/2.

   Usage of multiple time sources, or multiple network paths to a given
   time source [Shpiner], may also serve to mitigate delay attacks if
   the adversary is in control of only some of the paths.

10.5.  Random number generation

   At various points in NTS, the generation of cryptographically secure
   random numbers is required.  Whenever this draft specifies the use of
   random numbers, then cryptographically secure random number
   generation MUST be used.  See [RFC4086] for guidelines concerning
   this topic.

11.  Privacy Considerations

11.1.  Unlinkability

   Unlinkability prevents a device from being tracked when it changes
   network addresses (e.g. because said device moved between different
   networks).  In other words, unlinkability thwarts an attacker that
   seeks to link a new network address used by a device with a network
   address that it was formerly using, because of recognizable data that
   the device persistently sends as part of an NTS-secured NTP
   association.  This is the justification for continually supplying the
   client with fresh cookies, so that a cookie never represents
   recognizable data in the sense outlined above.

   NTS's unlinkability objective is merely to not leak any additional
   data that could be used to link a device's network address.  NTS does
   not rectify legacy linkability issues that are already present in
   NTP.  Thus, a client that requires unlinkability must also minimize
   information transmitted in a client query (mode 3) packet as
   described in the draft [I-D.ietf-ntp-data-minimization].

Franke, et al.           Expires January 2, 2019               [Page 28]
Internet-Draft                   NTS4NTP                       July 2018

   The unlinkability objective only holds for time synchronization
   traffic, as opposed to key exchange traffic.  This implies that it
   cannot be guaranteed for devices that function not only as time
   clients, but also as time servers (because the latter can be
   externally triggered to send authentication data).

   It should also be noted that it could be possible to link devices
   that operate as time servers from their time synchronization traffic,
   using information exposed in (mode 4) server response packets (e.g.
   reference ID, reference time, stratum, poll).  Also, devices that
   respond to NTP control queries could be linked using the information
   revealed by control queries.

11.2.  Confidentiality

   NTS does not protect the confidentiality of information in NTP's
   header fields.  When clients implement
   [I-D.ietf-ntp-data-minimization], client packet headers do not
   contain any information which the client could conceivably wish to
   keep secret: one field is random, and all others are fixed.
   Information in server packet headers is likewise public: the origin
   timestamp is copied from the client's (random) transmit timestamp,
   and all other fields are set the same regardless of the identity of
   the client making the request.

   Future extension fields could hypothetically contain sensitive
   information, in which case NTS provides a mechanism for encrypting
   them.

12.  Acknowledgements

   The authors would like to thank Richard Barnes, Steven Bellovin,
   Scott Fluhrer, Sharon Goldberg, Russ Housley, Martin Langer, Miroslav
   Lichvar, Aanchal Malhotra, Dave Mills, Danny Mayer, Karen O'Donoghue,
   Eric K.  Rescorla, Stephen Roettger, Kurt Roeckx, Kyle Rose, Rich
   Salz, Brian Sniffen, Susan Sons, Douglas Stebila, Harlan Stenn,
   Martin Thomson, and Richard Welty for contributions to this document
   and comments on the design of NTS.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Franke, et al.           Expires January 2, 2019               [Page 29]
Internet-Draft                   NTS4NTP                       July 2018

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
              2008, <https://www.rfc-editor.org/info/rfc5297>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <https://www.rfc-editor.org/info/rfc5705>.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
              <https://www.rfc-editor.org/info/rfc5746>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/info/rfc7301>.

   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,
              <https://www.rfc-editor.org/info/rfc7465>.

   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
              <https://www.rfc-editor.org/info/rfc7507>.

Franke, et al.           Expires January 2, 2019               [Page 30]
Internet-Draft                   NTS4NTP                       July 2018

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <https://www.rfc-editor.org/info/rfc7627>.

   [RFC7822]  Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
              (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
              March 2016, <https://www.rfc-editor.org/info/rfc7822>.

13.2.  Informative References

   [I-D.ietf-ntp-data-minimization]
              Franke, D. and A. Malhotra, "NTP Client Data
              Minimization", draft-ietf-ntp-data-minimization-00 (work
              in progress), May 2017.

   [Mizrahi]  Mizrahi, T., "A game theoretic analysis of delay attacks
              against time synchronization protocols", in Proceedings
              of Precision Clock Synchronization for Measurement Control
              and Communication, ISPCS 2012, pp. 1-6, September 2012.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <https://www.rfc-editor.org/info/rfc5077>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

Franke, et al.           Expires January 2, 2019               [Page 31]
Internet-Draft                   NTS4NTP                       July 2018

   [Shpiner]  "Multi-path Time Protocols", in Proceedings of IEEE
              International Symposium on Precision Clock Synchronization
              for Measurement, Control and Communication (ISPCS),
              September 2013.

Appendix A.  Terms and Abbreviations

   AEAD  Authenticated Encryption with Associated Data [RFC5116]

   DDoS  Distributed Denial of Service

   NTP   Network Time Protocol [RFC5905]

   NTS   Network Time Security

   TLS   Transport Layer Security

Authors' Addresses

   Daniel Fox Franke

   Email: dfoxfranke@gmail.com
   URI:   https://www.dfranke.us

   Dieter Sibold
   Physikalisch-Technische Bundesanstalt
   Bundesallee 100
   Braunschweig  D-38116
   Germany

   Phone: +49-(0)531-592-8420
   Fax:   +49-531-592-698420
   Email: dieter.sibold@ptb.de

   Kristof Teichel
   Physikalisch-Technische Bundesanstalt
   Bundesallee 100
   Braunschweig  D-38116
   Germany

   Phone: +49-(0)531-592-4471
   Email: kristof.teichel@ptb.de

Franke, et al.           Expires January 2, 2019               [Page 32]