<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ntp-using-nts-for-ntp-03"
     ipr="trust200902" submissionType="IETF">
  <front>
    <title abbrev="NTS4NTP">Using the Network Time Security Specification to
    Secure the Network Time Protocol</title>

    <author fullname="Dieter Sibold" initials="D." surname="Sibold">
      <organization abbrev="PTB">Physikalisch-Technische
      Bundesanstalt</organization>

      <address>
        <postal>
          <street>Bundesallee 100</street>

          <city>Braunschweig</city>

          <code>D-38116</code>

          <region/>

          <country>Germany</country>
        </postal>

        <phone>+49-(0)531-592-8420</phone>

        <facsimile>+49-531-592-698420</facsimile>

        <email>dieter.sibold@ptb.de</email>
      </address>
    </author>

    <author fullname="Stephen R&ouml;ttger" initials="S."
            surname="R&ouml;ttger">
      <organization>Google Inc</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>stephen.roettger@googlemail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Kristof Teichel" initials="K." surname="Teichel">
      <organization abbrev="PTB">Physikalisch-Technische
      Bundesanstalt</organization>

      <address>
        <postal>
          <street>Bundesallee 100</street>

          <city>Braunschweig</city>

          <region/>

          <code>D-38116</code>

          <country>Germany</country>
        </postal>

        <phone>+49-(0)531-592-8421</phone>

        <facsimile/>

        <email>kristof.teichel@ptb.de</email>

        <uri/>
      </address>
    </author>

    <date day="21" month="December" year="2015"/>

    <area>Internet Area</area>

    <workgroup>NTP Working Group</workgroup>

    <keyword>Integrity</keyword>

    <keyword>Authentication</keyword>

    <keyword>NTP</keyword>

    <keyword>Security</keyword>

    <abstract>
      <t>This document describes how to use the measures described in the
      Network Time Security (NTS) specification to secure time synchronization
      with servers using the Network Time Protocol (NTP).</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>One of the most popular time synchronization protocols, the Network
      Time Protocol (NTP) <xref target="RFC5905"/>, currently does not provide
      adequate intrinsic security precautions. The Network Time Security draft
      <xref target="I-D.ietf-ntp-network-time-security"/> specifies security
      measures which can be used to enable time synchronization protocols to
      verify authenticity of the time server and integrity of the time
      synchronization protocol packets.</t>

      <t>This document provides detail on how to specifically use those
      measures to secure time synchronization between NTP clients and
      servers.</t>
    </section>

    <section title="Objectives">
      <t>The objectives of the NTS specification are as follows:<list
          style="symbols">
          <t>Authenticity: NTS enables an NTP client to authenticate its time
          server(s).</t>

          <t>Integrity: NTS protects the integrity of NTP time synchronization
          protocol packets via a message authentication code (MAC).</t>

          <t>Confidentiality: NTS does not provide confidentiality protection
          of the time synchronization packets.</t>

          <t>Authorization: NTS optionally enables the server to verify the
          client's authorization.</t>

          <t>Request-Response-Consistency: NTS enables a client to match an
          incoming response to a request it has sent. NTS also enables the
          client to deduce from the response whether its request to the server
          has arrived without alteration.</t>

          <t>Modes of operation: Both the unicast and the broadcast mode of
          NTP are supported.</t>

          <t>Hybrid mode: Both secure and insecure communication modes are
          possible for both NTP servers and clients.</t>

          <t>Compatibility:<list style="symbols">
              <t>Unsecured NTP associations are not affected.</t>

              <t>An NTP server that does not support NTS is not affected by
              NTS-secured authentication requests.</t>
            </list></t>
        </list></t>
    </section>

    <section title="Terms and Abbreviations">
      <t><list style="hanging">
          <t hangText="CMS">Cryptographic Message Syntax <xref
          target="RFC5652"/></t>

          <t hangText="HMAC">Keyed-Hash Message Authentication Code</t>

          <t hangText="MAC">Message Authentication Code</t>

          <t hangText="MITM ">Man In The Middle</t>

          <t hangText="NTP  ">Network Time Protocol <xref
          target="RFC5905"/></t>

          <t hangText="NTS  ">Network Time Security</t>

          <t hangText="TESLA">Timed Efficient Stream Loss-Tolerant
          Authentication <xref target="RFC4082"/></t>
        </list></t>
    </section>

    <section title="Overview of NTS-Secured NTP">
      <section anchor="overview" title="Symmetric and Client/Server Mode">
        <t>The server does not keep a state of the client. NTS initially
        verifies the authenticity of the time server and exchanges a symmetric
        key, the so-called cookie and a key input value (KIV). The
        "association" and "cookie" message exchanges described in <xref
        target="I-D.ietf-ntp-network-time-security"/>, Appendix B., can be
        utilized for the exchange of the cookie and KIV. An implementation
        MUST support the use of these exchanges. It MAY additionally support
        the use of any alternative secure communication for this purpose, as
        long as it fulfills the preconditions given in <xref
        target="I-D.ietf-ntp-network-time-security"/>, Section 6.1.1.</t>

        <t>After the cookie and KIV are exchanged, the participants then use
        them to protect the authenticity and the integrity of subsequent
        unicast-type time synchronization packets. In order to do this, the
        server attaches a Message Authentication Code (MAC) to each time
        synchronization packet. The calculation of the MAC includes the whole
        time synchronization packet and the cookie which is shared between
        client and server. Therefore, the client can perform a validity check
        for this MAC on reception of a time synchronization packet.</t>
      </section>

      <section title="Broadcast Mode">
        <t>After the client has accomplished the necessary initial time
        synchronization via client-server mode, the necessary broadcast
        parameters are communicated from the server to the client. The
        "broadcast parameter" message exchange described in <xref
        target="I-D.ietf-ntp-network-time-security"/>, Appendix B., can be
        utilized for this communication. An implementation MUST support the
        use of this exchange. It MAY additionally support the use of any
        alternative secure communication for this purpose, as long as it
        fulfills the necessary security goals (given in <xref
        target="I-D.ietf-ntp-network-time-security"/>, Section 6.2.1.).</t>

        <t>After the client has received the necessry broadcast parameters,
        "broadcast time synchronization" message exchanges are utilized in
        combination with optional "broadcast keycheck" exchanges to protect
        authenticity and integrity of NTP broadcast time synchronization
        packets. As in the case of unicast time synchronization messages, this
        is also achieved by MACs.</t>
      </section>
    </section>

    <section title="Protocol Sequence">
      <t>Throughout this section, the server seed, the nonces, cookies and
      MACs mentioned have bit lengths of B_seed, B_nonce, B_cookie and B_mac,
      respectively. These bit lengths are defined in <xref
      target="appendix_bit_lengths">Appendix B</xref>.</t>

      <t>Note for clarification that different message exchanges use different
      nonces. A nonce is always generated by the client for a request message,
      and then used by the server in its response. After this, it is not to be
      used again.</t>

      <section title="The Client">
        <section anchor="clientinunicast" title="The Client in Unicast Mode">
          <t>For a unicast run, the client performs the following steps: <list
              style="hanging">
              <t hangText="NOTE:">Steps 1 through 4 MAY alternatively be
              replaced an alternative secure mechanism for association and
              cookie exchange. An implementation MAY choose to replace either
              steps 1 and 2 or all of the steps 1 through 4 by alternative
              secure communication.</t>

              <t hangText="Step 1:">It sends a client_assoc message to the
              server. It MUST keep the transmitted nonce as well as the values
              for the version number and algorithms available for later
              checks.</t>

              <t hangText="Step 2:">It waits for a reply in the form of a
              server_assoc message. After receipt of the message it performs
              the following checks: <list style="symbols">
                  <t>The client checks that the message contains a conforming
                  version number.</t>

                  <t>It checks that the nonce sent back by the server matches
                  the one transmitted in client_assoc,</t>

                  <t>It also verifies that the server has chosen the
                  encryption and hash algorithms from its proposal sent in the
                  client_assoc message and that this proposal was not
                  altered.</t>

                  <t>Furthermore, it performs authenticity checks on the
                  certificate chain and the signature.</t>
                </list>If one of the checks fails, the client MUST abort the
              run.<list style="hanging">
                  <t hangText="Discussion:">Note that by performing the above
                  message exchange and checks, the client validates the
                  authenticity of its immediate NTP server only. It does not
                  recursively validate the authenticity of each NTP server on
                  the time synchronization chain. Recursive authentication
                  (and authorization) as formulated in <xref
                  target="RFC7384">RFC 7384</xref> depends on the chosen trust
                  anchor.</t>
                </list></t>

              <t hangText="Step 3:">Next it sends a client_cook message to the
              server. The client MUST save the included nonce until the reply
              has been processed.</t>

              <t hangText="Step 4:">It awaits a reply in the form of a
              server_cook message; upon receipt it executes the following
              actions: <list style="symbols">
                  <t>It verifies that the received version number matches the
                  one negotiated beforehand.</t>

                  <t>It verifies the signature using the server's public key.
                  The signature has to authenticate the encrypted data.</t>

                  <t>It decrypts the encrypted data with its own private
                  key.</t>

                  <t>It checks that the decrypted message is of the expected
                  format: the concatenation of a B_nonce bit nonce and a
                  B_cookie bit cookie.</t>

                  <t>It verifies that the received nonce matches the nonce
                  sent in the client_cook message.</t>
                </list>If one of those checks fails, the client MUST abort the
              run.</t>

              <t hangText="Step 5:">The client sends a time_request message to
              the server. The client MUST append a MAC to the time_request
              message. The client MUST save the included nonce and the
              transmit_timestamp (from the time synchronization data) as a
              correlated pair for later verification steps.</t>

              <t hangText="Step 6:">It awaits a reply in the form of a
              time_response message. Upon receipt, it checks: <list
                  style="symbols">
                  <t>that the transmitted version number matches the one
                  negotiated previously,</t>

                  <t>that the transmitted nonce belongs to a previous
                  time_request message,</t>

                  <t>that the transmit_timestamp in that time_request message
                  matches the corresponding time stamp from the
                  synchronization data received in the time_response, and</t>

                  <t>that the appended MAC verifies the received
                  synchronization data, version number and nonce.</t>
                </list>If at least one of the first three checks fails (i.e.
              if the version number does not match, if the client has never
              used the nonce transmitted in the time_response message, or if
              it has used the nonce with initial time synchronization data
              different from that in the response), then the client MUST
              ignore this time_response message. If the MAC is invalid, the
              client MUST do one of the following: abort the run or go back to
              step 3 (because the cookie might have changed due to a server
              seed refresh). If both checks are successful, the client SHOULD
              continue time synchronization by repeating the exchange of
              time_request and time_response messages.</t>
            </list>The client's behavior in unicast mode is also expressed in
          <xref target="fig_flow_unicast"/>.</t>
        </section>

        <section title="The Client in Broadcast Mode">
          <t>To establish a secure broadcast association with a broadcast
          server, the client MUST initially authenticate the broadcast server
          and securely synchronize its time with it up to an upper bound for
          its time offset in unicast mode. After that, the client performs the
          following steps: <list style="hanging">
              <t hangText="NOTE:">Steps 1 and 2 MAY be replaced by an
              alternative security mechanism for the broadcast parameter
              exchange.</t>

              <t hangText="Step 1:">It sends a client_bpar message to the
              server. It MUST remember the transmitted values for the nonce,
              the version number and the signature algorithm.</t>

              <t hangText="Step 2:">It waits for a reply in the form of a
              server_bpar message after which it performs the following
              checks: <list style="symbols">
                  <t>The message must contain all the necessary information
                  for the TESLA protocol, as specified for a server_bpar
                  message.</t>

                  <t>The message must contain a nonce belonging to a
                  client_bpar message that the client has previously sent.</t>

                  <t>Verification of the message's signature.</t>
                </list>If any information is missing or if the server's
              signature cannot be verified, the client MUST abort the
              broadcast run. If all checks are successful, the client MUST
              remember all the broadcast parameters received for later
              checks.</t>

              <t hangText="Step 3:">The client awaits time synchronization
              data in the form of a server_broadcast message. Upon receipt, it
              performs the following checks: <list style="numbers">
                  <t>Proof that the MAC is based on a key that is not yet
                  disclosed (packet timeliness). This is achieved via a
                  combination of checks. First, the disclosure schedule is
                  used, which requires loose time synchronization. If this is
                  successful, the client obtains a stronger guarantee via a
                  key check exchange: it sends a client_keycheck message and
                  waits for the appropriate response. Note that it needs to
                  memorize the nonce and the time interval number that it
                  sends as a correlated pair. For more detail on both of the
                  mentioned timeliness checks, see <xref
                  target="I-D.ietf-ntp-network-time-security"/>. If its
                  timeliness is verified, the packet will be buffered for
                  later authentication. Otherwise, the client MUST discard it.
                  Note that the time information included in the packet will
                  not be used for synchronization until its authenticity could
                  also be verified.</t>

                  <t>The client checks that it does not already know the
                  disclosed key. Otherwise, the client SHOULD discard the
                  packet to avoid a buffer overrun. If verified, the client
                  ensures that the disclosed key belongs to the one-way key
                  chain by applying the one-way function until equality with a
                  previous disclosed key is shown. If it is falsified, the
                  client MUST discard the packet.</t>

                  <t>If the disclosed key is legitimate, then the client
                  verifies the authenticity of any packet that it has received
                  during the corresponding time interval. If authenticity of a
                  packet is verified it is released from the buffer and the
                  packet's time information can be utilized. If the
                  verification fails, then authenticity is no longer given. In
                  this case, the client MUST request authentic time from the
                  server by means of a unicast time request message. Also, the
                  client MUST re-initialize the broadcast sequence with a
                  "client_bpar" message if the one-way key chain expires,
                  which it can check via the disclosure schedule.</t>
                </list>See <xref target="RFC4082">RFC 4082</xref> for a
              detailed description of the packet verification process.</t>
            </list>The client MUST restart the broadcast sequence with a
          client_bpar message (<xref
          target="I-D.ietf-ntp-network-time-security"/>) if the one-way key
          chain expires.</t>

          <t>The client's behavior in broadcast mode can also be seen in <xref
          target="fig_flow_broadcast"/>.</t>
        </section>
      </section>

      <section title="The Server">
        <section title="The Server in Unicast Mode">
          <t>To support unicast mode, the server MUST be ready to perform the
          following actions: <list style="symbols">
              <t>Upon receipt of a client_assoc message, the server constructs
              and sends a reply in the form of a server_assoc message as
              described in <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>

              <t>Upon receipt of a client_cook message, the server checks
              whether it supports the given cryptographic algorithms. It then
              calculates the cookie according to the formula given in <xref
              target="I-D.ietf-ntp-network-time-security"/>. With this, it
              MUST construct a server_cook message as described in <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>

              <t>Upon receipt of a time_request message, the server
              re-calculates the cookie, verifies integrity of the message,
              then computes the necessary time synchronization data and
              constructs a time_response message as given in <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>
            </list>The server MUST refresh its server seed periodically (see
          <xref target="I-D.ietf-ntp-network-time-security"/>).</t>

          <t>In addition to the server MAY be ready to perform the following
          action:<list style="symbols">
              <t>If an external mechanism for association and key exchange is
              used, the server has to react accordingly.</t>
            </list></t>
        </section>

        <section title="The Server in Broadcast Mode">
          <t>A broadcast server MUST also support unicast mode in order to
          provide the initial time synchronization, which is a precondition
          for any broadcast association. To support NTS broadcast, the server
          MUST additionally be ready to perform the following actions: <list
              style="symbols">
              <t>Upon receipt of a client_bpar message, the server constructs
              and sends a server_bpar message as described in <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>

              <t>Upon receipt of a client_keycheck message, the server looks
              up whether it has already disclosed the key associated with the
              interval number transmitted in that message. If it has not
              disclosed it, it constructs and sends the appropriate
              server_keycheck message as described in <xref
              target="I-D.ietf-ntp-network-time-security"/>. For more details,
              see also <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>

              <t>The server follows the TESLA protocol in all other aspects,
              by regularly sending server_broad messages as described in <xref
              target="I-D.ietf-ntp-network-time-security"/>, adhering to its
              own disclosure schedule.</t>
            </list>The server is responsible to watch for the expiration date
          of the one-way key chain and generate a new key chain
          accordingly.</t>

          <t>In addition to the items above, the server MAY be ready to
          perform the following action:<list style="symbols">
              <t>Upon receipt of external communication for the purpose of
              broadcast parameter exchange, the server reacts according to the
              way the external communication is specified.</t>
            </list></t>
        </section>
      </section>
    </section>

    <section title="Implementation Notes: ASN.1 Structures and Use of the CMS">
      <t>This section presents some hints about the structures of the
      communication packets for the different message types when one wishes to
      implement NTS for NTP. See document <xref
      target="I-D.ietf-ntp-cms-for-nts-message"/> for descriptions of the
      archetypes for CMS structures as well as for the ASN.1 structures that
      are referenced here.</t>

      <t>All extension fields mentioned in the following list are notified by
      a field type value signalling content related to NTS version 1.0.</t>

      <section title="Unicast Messages">
        <section title="Association Messages">
          <section title="Message Type: &quot;client_assoc&quot;">
            <t>This message is realized as an NTP packet with an extension
            field which holds an "NTS-Plain" archetype structure. This
            structure consists only of an NTS message object of the type
            "ClientAssocData", which holds all the data necessary for the NTS
            security mechanisms.</t>
          </section>

          <section title="Message Type: &quot;server_assoc&quot;">
            <t>Like "client_assoc", this message is realized as an NTP packet
            with an extension field which holds an "NTS-Plain" archetype
            structure, i.e. just an NTS message object of the type
            "ServerAssocData". The latter holds all the data necessary for
            NTS.</t>
          </section>
        </section>

        <section title="Cookie Messages">
          <section title="Message Type: &quot;client_cook&quot;">
            <t>This message type is realized as an NTP packet with an
            extension field which holds a CMS structure of archetype
            "NTS-Plain", containing in its core an NTS message object of the
            type "ClientCookieData". The latter holds all the data necessary
            for the NTS security mechanisms.</t>
          </section>

          <section title="Message Type: &quot;server_cook&quot;">
            <t>This message type is realized as an NTP packet with an
            extension field containing a CMS structure of archetype
            "NTS-Encrypted-and-Signed". The NTS message object in that
            structure is a "ServerCookieData" object, which holds all data
            required by NTS for this message type.</t>
          </section>
        </section>

        <section title="Time Synchronization Messages">
          <section title="Message Type: &quot;time_request&quot;">
            <t>This message type is realized as an NTP packet with regular NTP
            time synchronization data. Furthermore, the packet has an
            extension field which contains an ASN.1 object of type
            "TimeRequestSecurityData" (packed in a CMS structure of archetype
            "NTS-Plain"). Finally, this NTP packet has another extension field
            which contains a Message Authentication Code generated over the
            whole packet (including the extension field).</t>
          </section>

          <section title="Message Type: &quot;time_response&quot;">
            <t>This message is also realized as an NTP packet with regular NTP
            time synchronization data. The packet also has an extension field
            which contains an ASN.1 object of type "TimeResponseSecurityData".
            Finally, this NTP packet has another extension field which
            contains a Message Authentication Code generated over the whole
            packet (including the extension field).</t>
          </section>
        </section>
      </section>

      <section title="Broadcast Messages">
        <section title="Broadcast Parameter Messages">
          <section title="Message Type: &quot;client_bpar&quot;">
            <t>This first broadcast message is realized as an NTP packet which
            is empty except for an extension field which contains an ASN.1
            object of type "BroadcastParameterRequest" (packed in a CMS
            structure of archetype "NTS-Plain"). This is sufficient to
            transport all data specified by NTS.</t>
          </section>

          <section title="Message Type: &quot;server_bpar&quot;">
            <t>This message type is realized as an NTP packet whose extension
            field carries the necessary CMS structure (archetype:
            "NTS-Signed"). The NTS message object in this case is an ASN.1
            object of type "BroadcastParameterResponse".</t>
          </section>
        </section>

        <section title="Broadcast Time Synchronization Message">
          <section title="Message Type: &quot;server_broad&quot;">
            <t>This message's realization works via an NTP packet which
            carries regular NTP broadcast time data as well as an extension
            field, which contains an ASN.1 object of type "BroadcastTime"
            (packed in a CMS structure with archetype "NTS-Plain"). In
            addition to all this, this packet has another extension field
            which contains a Message Authentication Code generated over the
            whole packet (including the extension field).</t>
          </section>
        </section>

        <section title="Broadcast Keycheck">
          <section title="Message Type: &quot;client_keycheck&quot;">
            <t>This message is realized as an NTP packet with an extension
            field, which transports a CMS structure of archetype "NTS-Plain",
            containing an ASN.1 object of type
            "ClientKeyCheckSecurityData".</t>
          </section>

          <section title="Message Type: &quot;server_keycheck&quot;">
            <t>This message is also realized as an NTP packet with an
            extension field, which contains an ASN.1 object of type
            "ServerKeyCheckSecurityData" (packed in a CMS structure of
            archetype "NTS-Plain"). Additionally, this NTP packet has another
            extension field which contains a Message Authentication Code
            generated over the whole packet (including the extension
            field).</t>
          </section>
        </section>
      </section>
    </section>

    <section title="IANA Considerations">
      <t/>

      <section title="Field Type Registry">
        <t>Within the "NTP Extensions Field Types" registry table, add one
        field type:</t>

        <figure>
          <artwork><![CDATA[      Field Type  Meaning                              References     
      ----------  ------------------------------------ ----------
      TBD1        NTS-Related Content                  [this doc]]]></artwork>
        </figure>
      </section>
    </section>

    <section title="Security Considerations">
      <section title="Employing Alternative Means for Association and Cookie Exchange">
        <t>If an implementation uses alternative means to perform association
        and cookie exchange, it MUST make sure that an adversary cannot abuse
        the server to obtain a cookie belonging to a chosen KIV.</t>
      </section>

      <section title="Usage of NTP Pools">
        <t>The certification-based authentication scheme described in <xref
        target="I-D.ietf-ntp-network-time-security"/> is not applicable to the
        concept of NTP pools. Therefore, NTS is unable to provide secure usage
        of NTP pools.</t>
      </section>

      <section title="Server Seed Lifetime">
        <t>tbd</t>
      </section>

      <section title="Supported Hash Algorithms">
        <t>The list of the hash algorithms supported by the server has to
        fulfill the following requirements:</t>

        <t><list style="symbols">
            <t>it MUST NOT include SHA-1 or weaker algorithms,</t>

            <t>it MUST include SHA-256 or stronger algorithms.</t>
          </list></t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Russ Housley, Steven Bellovin, David
      Mills and Kurt Roeckx for discussions and comments on the design of NTS.
      Also, thanks to Harlan Stenn for his technical review and specific text
      contributions to this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.5905'?>

      <?rfc include='reference.RFC.4082'?>

      <?rfc include='reference.RFC.5652'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7384'?>

      <?rfc include='reference.I-D.draft-ietf-ntp-cms-for-nts-message-04'?>

      <?rfc include='reference.I-D.draft-ietf-ntp-network-time-security-11'?>
    </references>

    <section title="Flow Diagrams of Client Behaviour">
      <figure anchor="fig_flow_unicast"
              title="The client's behavior in NTS unicast mode.">
        <artwork><![CDATA[                     +---------------------+
                     |Association Messages |
                     +----------+----------+
                                |
+------------------------------>o
|                               |
|                               v
|                       +---------------+
|                       |Cookie Messages|
|                       +-------+-------+
|                               |
|                               o<------------------------------+
|                               |                               |
|                               v                               |
|                     +-------------------+                     |
|                     |Time Sync. Messages|                     |
|                     +---------+---------+                     |
|                               |                               |
|                               v                               |
|                            +-----+                            |
|                            |Check|                            |
|                            +--+--+                            |
|                               |                               |
|            /------------------+------------------\            |
|           v                   v                   v           |
|     .-----------.      .-------------.        .-------.       |
|    ( MAC Failure )    ( Nonce Failure )      ( Success )      |
|     '-----+-----'      '------+------'        '---+---'       |
|           |                   |                   |           |
|           v                   v                   v           |
|    +-------------+     +-------------+     +--------------+   |
|    |Discard Data |     |Discard Data |     |Sync. Process |   |
|    +-------------+     +------+------+     +------+-------+   |
|           |                   |                   |           |
|           |                   |                   v           |
+-----------+                   +------------------>o-----------+]]></artwork>
      </figure>

      <figure anchor="fig_flow_broadcast"
              title="The client's behaviour in NTS broadcast mode.">
        <artwork><![CDATA[                         +-----------------------------+
                         |Broadcast Parameter Messages |
                         +--------------+--------------+
                                        |
                                        o<--------------------------+
                                        |                           |
                                        v                           |
                         +-----------------------------+            |
                         |Broadcast Time Sync. Message |            |
                         +--------------+--------------+            |
                                        |                           |
+-------------------------------------->o                           |
|                                       |                           |
|                                       v                           |
|                             +-------------------+                 |
|                             |Key and Auth. Check|                 |
|                             +---------+---------+                 |
|                                       |                           |
|                      /----------------*----------------\          |
|                     v                                   v         |
|                .---------.                         .---------.    |
|               ( Verified  )                       ( Falsified )   |
|                '----+----'                         '----+----'    |
|                     |                                   |         |
|                     v                                   v         |
|              +-------------+                        +-------+     |
|              |Store Message|                        |Discard|     |
|              +------+------+                        +---+---+     |
|                     |                                   |         |
|                     v                                   +---------o
|             +---------------+                                     |
|             |Check Previous |                                     |
|             +-------+-------+                                     |
|                     |                                             |
|            /--------*--------\                                    |
|           v                   v                                   |
|      .---------.         .---------.                              |
|     ( Verified  )       ( Falsified )                             |
|      '----+----'         '----+----'                              |
|           |                   |                                   |
|           v                   v                                   |
|    +-------------+   +-----------------+                          |
|    |Sync. Process|   |Discard Previous |                          |
|    +------+------+   +--------+--------+                          |
|           |                   |                                   |
+-----------+                   +-----------------------------------+]]></artwork>
      </figure>
    </section>

    <section anchor="appendix_bit_lengths"
             title="Bit Lengths for Employed Primitives">
      <t>Define the following bit lengths for server seed, nonces, cookies and
      MACs:<list style="hanging">
          <t>B_seed = 128,</t>

          <t>B_nonce = 128,</t>

          <t>B_cookie = 128, and</t>

          <t>B_mac = 128.</t>
        </list></t>
    </section>
  </back>
</rfc>
