<?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-cms-for-nts-message-06"
     ipr="trust200902" submissionType="IETF">
  <front>
    <title abbrev="CMS4NTS">Protecting Network Time Security Messages with the
    Cryptographic Message Syntax (CMS)</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="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>

    <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="Russ Housley" initials="R." surname="Housley">
      <organization>Vigil Security</organization>

      <address>
        <postal>
          <street>918 Spring Knoll Drive</street>

          <region>Herndon, VA 20170</region>
        </postal>

        <phone/>

        <facsimile/>

        <email>housley@vigilsec.com</email>

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

    <date day="25" month="February" year="2016"/>

    <area>Internet Area</area>

    <workgroup>NTP Working Group</workgroup>

    <keyword>NTP</keyword>

    <keyword>PTP</keyword>

    <keyword>Security</keyword>

    <keyword>CMS</keyword>

    <keyword>NTS</keyword>

    <abstract>
      <t>This document describes a convention for using the Cryptographic
      Message Syntax (CMS) to protect the messages in the Network Time
      Security (NTS) protocol. NTS provides authentication of time servers as
      well as integrity protection of time synchronization messages using
      Network Time Protocol (NTP) or Precision Time Protocol (PTP).</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>This document provides details on how to construct NTS messages in
      practice. NTS provides secure time synchronization with time servers
      using Network Time Protocol (NTP) <xref target="RFC5905"/> or Precision
      Time Protocol (PTP) <xref target="IEEE1588"/>. Among other things, this
      document describes a convention for using the Cryptographic Message
      Syntax (CMS) <xref target="RFC5652"/> to protect messages in the Network
      Time Security (NTS) protocol. Encryption is used to provide
      confidentiality of secrets, and digital signatures are used to provide
      authentication and integrity of content.</t>

      <t>Sometimes CMS is used in an exclusively ASN.1 <xref target="ASN1"/>
      environment. In this case, the NTS message may use any syntax that
      facilitates easy implementation.</t>
    </section>

    <section title="CMS Conventions for NTS Message Protection">
      <t>Regarding the usage of CMS, we differentiate between three archetypes
      according to which the NTS message types can be structured. They are
      presented below. Note that the NTS Message Object that is at the core of
      each structure does not necessarily contain all the data needed for the
      particular message type, but may contain only that data which needs to
      be secured directly with cryptographic operations using the CMS.
      Specific information about what is included can be found in <xref
      target="implementationNotes"/>.</t>

      <t><list style="hanging">
          <t hangText="NTS-Plain:">This archetype is used for actual time
          synchronization messages (explicitly, the following message types:
          time_request, time_response, server_broad, see <xref
          target="I-D.ietf-ntp-network-time-security"/>, Section 6) as well as
          for client-side messages of all unicast and broadcast bootstrapping
          exchanges (explicitly client_assoc, client_cook and client_bpar) as
          well as the broadcast keycheck exchange (client_keycheck and
          server_keycheck). This archetype does not make use of any CMS
          structures at all. Figure 1 illustrates this structure.<figure>
              <artwork><![CDATA[
   +-----------------------------------------------------+
   |                                                     |
   | NTS Message Object                                  |
   |                                                     |
   |                                                     |
   +-----------------------------------------------------+

]]></artwork>
            </figure></t>

          <t hangText="NTS-Encrypted-and-Signed:">This archetype is used for
          secure transmission of the cookie (only for the server_cook message
          type, see <xref target="I-D.ietf-ntp-network-time-security"/>,
          Section 6). For this, the following CMS structure is used:<list
              style="empty">
              <t>First, the NTS message MUST be encrypted using the
              EnvelopedData content type. EnvelopedData supports nearly any
              form of key management. In the NTS protocol the client provides
              a certificate in an unprotected message, and the public key from
              this certificate, if it is valid, will be used to establish a
              pairwise symmetric key for the encryption of the protected NTS
              message.</t>

              <t>Second, the EnvelopedData content MUST be digitally signed
              using the SignedData content type. SignedData supports nearly
              any form of digital signature, and in the NTS protocol the
              server will include its certificate within the SignedData
              content type.</t>

              <t>Third, the SignedData content type MUST be encapsulated in a
              ContentInfo content type.</t>
            </list>Figure 2 illustrates this structure.<figure>
              <artwork><![CDATA[
   +---------------------------------------------------------+
   |                                                         |
   | ContentInfo                                             |
   |                                                         |
   | +-----------------------------------------------------+ |
   | |                                                     | |
   | | SignedData                                          | |
   | |                                                     | |
   | | +-------------------------------------------------+ | |
   | | |                                                 | | |
   | | | EnvelopedData                                   | | |
   | | |                                                 | | |
   | | | +---------------------------------------------+ | | |
   | | | |                                             | | | |
   | | | | NTS Message Object                          | | | |
   | | | |                                             | | | |
   | | | |                                             | | | |
   | | | +---------------------------------------------+ | | |
   | | |                                                 | | |
   | | +-------------------------------------------------+ | |
   | |                                                     | |
   | +-----------------------------------------------------+ |
   |                                                         |
   +---------------------------------------------------------+]]></artwork>
            </figure></t>

          <t hangText="NTS-Signed:">This archetype is used for server_assoc
          and server_bpar message types. It uses the following CMS
          structure:<list style="empty">
              <t>First, the NTS message object MUST be wrapped in a SignedData
              content type. The messages MUST be digitally signed, and
              certificates included. SignedData supports nearly any form of
              digital signature, and in the NTS protocol the server will
              include its certificate within the SignedData content type.</t>

              <t>Second, the SignedData content type MUST be encapsulated in a
              ContentInfo content type.</t>
            </list> Figure 3 illustrates this structure.<figure>
              <artwork><![CDATA[
   +---------------------------------------------------------+
   |                                                         |
   | ContentInfo                                             |
   |                                                         |
   | +-----------------------------------------------------+ |
   | |                                                     | |
   | | SignedData                                          | |
   | |                                                     | |
   | | +-------------------------------------------------+ | |
   | | |                                                 | | |
   | | | NTS Message Object                              | | |
   | | |                                                 | | |
   | | |                                                 | | |
   | | +-------------------------------------------------+ | |
   | |                                                     | |
   | +-----------------------------------------------------+ |
   |                                                         |
   +---------------------------------------------------------+]]></artwork>
            </figure></t>
        </list></t>

      <section title="Fields of the employed CMS Content Types">
        <t>Overall, three CMS content types are used for NTS messages by the
        archetypes above. Explicitly, those content types are ContentInfo,
        SignedData and EnvelopedData. The following is a description of how
        the fields of those content types are used in detail.</t>

        <section title="ContentInfo">
          <t>The ContentInfo content type is used in all archetypes except
          NTS-Plain. The fields of the ContentInfo content type are used as
          follows:<list style="hanging">
              <t>contentType -- indicates the type of the associated content.
              For all archetypes which use ContentInfo (these are NTS-Signed
              and NTS-Encrypted-and-Signed), it MUST contain the object
              identifier for the SignedData content type: <figure>
                  <artwork><![CDATA[        id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }]]></artwork>
                </figure></t>

              <t>content -- is the associated content. For all archetypes
              using ContentInfo, it MUST contain the DER encoded SignedData
              content type.</t>
            </list></t>
        </section>

        <section title="SignedData">
          <t>The SignedData content type is used in the NTS-Signed and
          NTS-Encrypted-and-Signed archetypes, but not in the NTS-Plain
          archetype. The fields of the SignedData content type are used as
          follows: <list style="hanging">
              <t>version -- the appropriate value depends on the optional
              items that are included. In the NTS protocol, the signer
              certificate MUST be included and other items MAY be included.
              The instructions in <xref target="RFC5652"/> Section 5.1 MUST be
              followed to set the correct value.</t>

              <t>digestAlgorithms -- is a collection of message digest
              algorithm identifiers. In the NTS protocol, there MUST be
              exactly one algorithm identifier present. The instructions in
              Section 5.4 of <xref target="RFC5652"/> MUST be followed.</t>

              <t>encapContentInfo -- this structure is always present. In the
              NTS protocol, it MUST follow these conventions:<list
                  style="hanging">
                  <t>eContentType -- is an object identifier. In the NTS
                  protocol, for the NTS-Signed archetype, it MUST identify the
                  type of the NTS message that was encapsulated. For the
                  NTS-Encrypted-and-Signed archetype, it MUST contain the
                  object identifier for the EnvelopedData content type:<figure>
                      <artwork><![CDATA[      id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }.]]></artwork>
                    </figure></t>

                  <t>eContent is the content itself, carried as an octet
                  string. For the NTS-Signed archetype, it MUST contain the
                  DER encoded encapsulated NTS message object. The
                  instructions in Section 6.3 of [RFC5652] MUST be followed.
                  For the NTS-Encrypted-and-Signed archetype, it MUST contain
                  the DER encoded EnvelopedData content type.</t>
                </list></t>

              <t>certificates -- is a collection of certificates. In the NTS
              protocol, it MUST contain the DER encoded certificate [RFC5280]
              of the sender. It is intended that the collection of
              certificates be sufficient for the recipient to construct a
              certification path from a recognized "root" or "top-level
              certification authority" to the certificate used by the
              sender.</t>

              <t>crls -- is a collection of revocation status information. In
              the NTS protocol, it MAY contain one or more DER encoded CRLs
              [RFC5280]. It is intended that the collection contain
              information sufficient to determine whether the certificates in
              the certificates field are valid.</t>

              <t>signerInfos -- is a collection of per-signer information. In
              the NTS protocol, for the NTS-Signed and the
              NTS-Encrypted-and-Signed archetypes, there MUST be exactly one
              SignerInfo structure present. The details of the SignerInfo type
              are discussed in Section 5.3 of <xref target="RFC5652"/>. In the
              NTS protocol, it MUST follow these conventions:<list
                  style="hanging">
                  <t>version -- is the syntax version number. In the NTS
                  protocol, the SignerIdentifier is subjectKeyIdentifier,
                  therefore the version MUST be 3.</t>

                  <t>sid -- identifies the signer's certificate. In the NTS
                  protocol, the "sid" field contains the subjectKeyIdentifier
                  from the signer's certificate.</t>

                  <t>digestAlgorithm -- identifies the message digest
                  algorithm and any associated parameters used by the signer.
                  In the NTS protocol, the identifier MUST match the single
                  algorithm identifier present in the digestAlgorithms.</t>

                  <t>signedAttrs -- is a collection of attributes that are
                  signed. In the NTS protocol, it MUST be present, and it MUST
                  contain the following attributes:<list style="hanging">
                      <t>Content Type -- see Section 11.1 of <xref
                      target="RFC5652"/>.</t>

                      <t>Message Digest -- see Section 11.2 of <xref
                      target="RFC5652"/>.</t>
                    </list>In addition, it MAY contain the following
                  attributes:<list style="hanging">
                      <t>Signing Time -- see Section 11.3 of <xref
                      target="RFC5652"/>.</t>

                      <t>Binary Signing Time -- see Section 3 of <xref
                      target="RFC5652"/>.</t>
                    </list></t>

                  <t>signatureAlgorithm -- identifies the signature algorithm
                  and any associated parameters used by the signer to generate
                  the digital signature.</t>

                  <t>signature is the result of digital signature generation
                  using the message digest and the signer's private key. The
                  instructions in Section 5.5 of <xref target="RFC5652"/> MUST
                  be followed.</t>

                  <t>unsignedAttrs -- is an optional collection of attributes
                  that are not signed. In the NTS protocol, it MUST be
                  absent.</t>
                </list></t>
            </list></t>
        </section>

        <section title="EnvelopedData">
          <t>The EnvelopedData content type is used only in the
          NTS-Encrypted-and-Signed archetype. The fields of the EnvelopedData
          content type are used as follows:<list style="hanging">
              <t>version -- the appropriate value depends on the type of key
              management that is used. The instructions in <xref
              target="RFC5652"/> Section 6.1 MUST be followed to set the
              correct value.</t>

              <t>originatorInfo -- this structure is present only if required
              by the key management algorithm. In the NTS protocol, it MUST be
              present when a key agreement algorithm is used, and it MUST be
              absent when a key transport algorithm is used. The instructions
              in Section 6.1 of <xref target="RFC5652"/> MUST be followed.</t>

              <t>recipientInfos -- this structure is always present. In the
              NTS protocol, it MUST contain exactly one entry that allows the
              client to determine the key used to encrypt the NTS message. The
              instructions in Section 6.2 of <xref target="RFC5652"/> MUST be
              followed.</t>

              <t>encryptedContentInfo -- this structure is always present. In
              the NTS protocol, it MUST follow these conventions:<list
                  style="hanging">
                  <t>contentType -- indicates the type of content. In the NTS
                  protocol, it MUST identify the type of the NTS message that
                  was encrypted.</t>

                  <t>contentEncryptionAlgorithm -- identifies the
                  content-encryption algorithm and any associated parameters
                  used to encrypt the content.</t>

                  <t>encryptedContent -- is the encrypted content. In the NTS
                  protocol, it MUST contain the encrypted NTS message. The
                  instructions in Section 6.3 of [RFC5652] MUST be
                  followed.</t>
                </list></t>

              <t>unprotectedAttrs -- this structure is optional. In the NTS
              protocol, it MUST be absent.</t>
            </list></t>
        </section>
      </section>
    </section>

    <section anchor="implementationNotes"
             title="Implementation Notes: ASN.1 Structures and Use of the CMS">
      <t>This section presents some hints about the structures of the NTS
      message objects for the different message types when one wishes to
      implement the security mechanisms.</t>

      <section title="Preliminaries">
        <t>The following ASN.1 coded data types "NTSAccessKey", "NTSNonce",
        and "NTSVersion" are needed for other types used below for NTS
        messages. "NTSAccessKey" specifies an access key, which is required
        for limitation of client association requests.</t>

        <figure>
          <artwork><![CDATA[NTSAccessKey ::= OCTET STRING (SIZE(16))
]]></artwork>
        </figure>

        <t>"NTSNonce" specifies a 128 bit nonce as required in several message
        types.</t>

        <figure>
          <artwork><![CDATA[NTSNonce ::= OCTET STRING (SIZE(16))
]]></artwork>
        </figure>

        <t>"NTSVersion" specifies a version number, which is required for
        version negotiation.</t>

        <figure>
          <artwork><![CDATA[NTSVersion ::= INTEGER (0..255)
]]></artwork>
        </figure>

        <t>The following ASN.1 coded data types are also necessary for other
        types.</t>

        <figure>
          <artwork><![CDATA[KeyEncryptionAlgorithmIdentifiers ::= 
    SET OF KeyEncryptionAlgorithmIdentifier
]]></artwork>
        </figure>

        <figure>
          <artwork><![CDATA[ContentEncryptionAlgorithmIdentifiers ::= 
    SET OF ContentEncryptionAlgorithmIdentifier
]]></artwork>
        </figure>
      </section>

      <section title="Unicast Messages">
        <section title="Access Messages">
          <section title="Message Type: &quot;client_access&quot;">
            <t>This message is structured according to the NTS-Plain
            archetype. There is no data necessary besides that which is
            transported in the NTS message object, which is an ASN.1 object of
            type "ClientAccessData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ClientAccessData ::= NULL]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-clientAccess OBJECT IDENTIFIER ::= TBD1]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;server_access&quot;">
            <t>This message is structured according to the NTS-Plain
            archetype. There is no data necessary besides that which is
            transported in the NTS message object, which is an ASN.1 object of
            type "ServerAccessData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ServerAccessData ::= SEQUENCE {
    accessKey         NTSAccessKey
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-serverAccess OBJECT IDENTIFIER ::= TBD2]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Association Messages">
          <section title="Message Type: &quot;client_assoc&quot;">
            <t>This message is structured according to the NTS-Plain
            archetype. There is no data necessary besides that which is
            transported in the NTS message object, which is an ASN.1 object of
            type "ClientAssocData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ClientAssocData ::= SEQUENCE {
    accessKey        NTSAccessKey,
    nonce            NTSNonce,
    minVersion       NTSVersion,
    hmacHashAlgos    DigestAlgorithmIdentifiers,
    keyEncAlgos      KeyEncryptionAlgorithmIdentifiers,
    contentEncAlgos  ContentEncryptionAlgorithmIdentifiers
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-clientAssoc OBJECT IDENTIFIER ::= TBD3]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;server_assoc&quot;">
            <t>This message is structured according to the NTS-Signed
            archetype. It requires additional data besides that which is
            transported in the NTS message object, namely the signature and
            certificate chain are included in the appropriate fields of the
            "SignedData" CMS structure that the NTS message object is wrapped
            in. The NTS message object itself is an ASN.1 object of type
            "ServerAssocData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ServerAssocData ::= SEQUENCE {
    nonce                 NTSNonce,
    proposedVersion       NTSVersion,
    hmacHashAlgos         DigestAlgorithmIdentifiers,
    choiceHmacHashAlgo    DigestAlgorithmIdentifier,
    keyEncAlgos           KeyEncryptionAlgorithmIdentifiers,
    choiceKeyEncAlgo      KeyEncryptionAlgorithmIdentifier,
    contentEncAlgos       ContentEncryptionAlgorithmIdentifiers,
    choiceContentEncAlgo  ContentEncryptionAlgorithmIdentifier
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-serverAssoc OBJECT IDENTIFIER ::= TBD4]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Cookie Messages">
          <section title="Message Type: &quot;client_cook&quot;">
            <t>This message is structured according to the NTS-Plain
            archetype. It requires no additional data besides that which is
            transported in the NTS message object. The NTS message object
            itself is an ASN.1 object of type "ClientCookieData" and
            structured as follows:</t>

            <figure>
              <artwork><![CDATA[ClientCookieData ::= SEQUENCE {
    nonce         NTSNonce,
    signAlgo      SignatureAlgorithmIdentifier,
    hmacHashAlgo  DigestAlgorithmIdentifier,
    encAlgo       ContentEncryptionAlgorithmIdentifier,
    keyEncAlgo    KeyEncryptionAlgorithmIdentifier,
    certificates  CertificateSet
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-clientCookie OBJECT IDENTIFIER ::= TBD5]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;server_cook&quot;">
            <t>This message is structured according to the
            "NTS-Encrypted-and-Signed" archetype. It requires additional data
            besides that which is transported in the NTS message object,
            namely the signature is included in the appropriate field of the
            "SignedData" CMS structure that the NTS message object is wrapped
            in. The NTS message object itself is an ASN.1 sequence of type
            "ServerCookieData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ServerCookieData ::= SEQUENCE {
    nonce     NTSNonce,
    cookie    OCTET STRING (SIZE(16))
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-serverCookie OBJECT IDENTIFIER ::= TBD6]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Time Synchronization Messages">
          <section title="Message Type: &quot;time_request&quot;">
            <t>This message is structured according to the "NTS-Plain"
            archetype.</t>

            <t>This message type requires additional data to that which is
            included in the NTS message object, namely it requires regular
            time synchronization data, as an unsecured packet from a client to
            a server would contain. Optionally, it requires the Message
            Authentication Code (MAC) to be generated over the whole rest of
            the packet (including the NTS message object) and transported in
            some way. The NTS message object itself is an ASN.1 object of type
            "TimeRequestSecurityData", whose structure is as follows:</t>

            <figure>
              <artwork><![CDATA[TimeRequestSecurityData ::= 
SEQUENCE {
    nonce           NTSNonce,
    hmacHashAlgo    DigestAlgorithmIdentifier,
    keyInputValue   OCTET STRING (SIZE(16))
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-securityDataReq OBJECT IDENTIFIER ::= TBD7]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;time_response&quot;">
            <t>This message is structured according to the "NTS-Plain"
            archetype.</t>

            <t>It requires two items of data in addition to that which is
            transported in the NTS message object. Like "time_request", it
            requires regular time synchronization data. Furthermore, it
            requires the Message Authentication Code (MAC) to be generated
            over the whole rest of the packet (including the NTS message
            object) and transported in some way. The NTS message object itself
            is an ASN.1 object of type "TimeResponseSecurityData", with the
            following structure:</t>

            <figure>
              <artwork><![CDATA[TimeResponseSecurityData ::= 
SEQUENCE {
    nonce    NTSNonce,
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-securityDataResp OBJECT IDENTIFIER ::= TBD8]]></artwork>
            </figure>
          </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 structured according to the
            NTS-Plain archetype. There is no data necessary besides that which
            is transported in the NTS message object, which is an ASN.1 object
            of type "BroadcastParameterRequest" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[BroadcastParameterRequest ::= 
SEQUENCE {
    nonce     NTSNonce,
    clientId  SubjectKeyIdentifier
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-broadcastParamReq OBJECT IDENTIFIER ::= TBD9]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;server_bpar&quot;">
            <t>This message is structured according to "NTS-Signed". It
            requires additional data besides that which is transported in the
            NTS message object, namely the signature is included in the
            appropriate field of the "SignedData" CMS structure that the NTS
            message object is wrapped in. The NTS message object itself is an
            ASN.1 object of type "BroadcastParameterResponse" and structured
            as follows:</t>

            <figure>
              <artwork><![CDATA[BroadcastParameterResponse ::= 
SEQUENCE {
    nonce               NTSNonce,
    oneWayAlgo1         DigestAlgorithmIdentifier,
    oneWayAlgo2         DigestAlgorithmIdentifier,
    lastKey             OCTET STRING (SIZE (16)),
    intervalDuration    BIT STRING,
    disclosureDelay     INTEGER,
    nextIntervalTime    BIT STRING,
    nextIntervalIndex   INTEGER
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-broadcastParamResp OBJECT IDENTIFIER ::= TBD10]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Broadcast Time Synchronization Message">
          <section title="Message Type: &quot;server_broad&quot;">
            <t>This message is structured according to the "NTS-Plain"
            archetype. It requires regular broadcast time synchronization data
            in addition to that which is carried in the NTS message object.
            Like "time_response", this message type also requires a MAC,
            generated over all other data, to be transported within the
            packet. The NTS message object itself is an ASN.1 object of type
            "BroadcastTime". It has the following structure:</t>

            <figure>
              <artwork><![CDATA[BroadcastTime ::= 
SEQUENCE {
    thisIntervalIndex   INTEGER,
    disclosedKey        OCTET STRING (SIZE (16)),
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-broadcastTime OBJECT IDENTIFIER ::= TBD11]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Broadcast Keycheck">
          <section title="Message Type: &quot;client_keycheck&quot;">
            <t>This message is structured according to the "NTS-Plain"
            archetype. There is no data necessary besides that which is
            transported in the NTS message object, which is an ASN.1 object of
            type "ClientKeyCheckSecurityData" and structured as follows:</t>

            <figure>
              <artwork><![CDATA[ClientKeyCheckSecurityData ::= 
SEQUENCE {
    nonce_k           NTSNonce,
    interval_number   INTEGER,
    hmacHashAlgo      DigestAlgorithmIdentifier,
    keyInputValue     OCTET STRING (SIZE(16))
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-clientKeyCheck OBJECT IDENTIFIER ::= TBD12]]></artwork>
            </figure>
          </section>

          <section title="Message Type: &quot;server_keycheck&quot;">
            <t>This message is also structured according to "NTS-Plain". It
            requires only a MAC, generated over the NTS message object, to be
            included in the packet in addition to what the NTS message object
            itself contains. The latter is an ASN.1 object of type
            "ServerKeyCheckSecurityData", which is structured as follows:</t>

            <figure>
              <artwork><![CDATA[ServerKeyCheckSecurityData ::= 
SEQUENCE {
    nonce             NTSNonce,
    interval_number   INTEGER
}]]></artwork>
            </figure>

            <t>It is identified by the following object identifier:</t>

            <figure>
              <artwork><![CDATA[id-ct-nts-serverKeyCheck OBJECT IDENTIFIER ::= TBD13]]></artwork>
            </figure>
          </section>
        </section>
      </section>
    </section>

    <section title="Certificate Conventions">
      <t>The syntax and processing rules for certificates are specified in
      <xref target="RFC5280"/>. In the NTS protocol, the server certificate
      MUST contain the following extensions: <list style="hanging">
          <t>Subject Key Identifier -- see Section 4.2.1.2 of <xref
          target="RFC5280"/>.</t>

          <t>Key Usage -- see Section 4.2.1.3 of <xref target="RFC5280"/>.</t>

          <t>Extended Key Usage -- see Section 4.2.1.12 of <xref
          target="RFC5280"/>.</t>
        </list>For a certificate issued to a time server, the Extended Key
      Usage extension MAY include the id-kp-ntsServerAuth object identifier.
      When a certificate issuer includes this object identifier in the
      extended key usage extension, it provides an attestation that the
      certificate subject is a time server that supports the NTS protocol. The
      extension MAY also include the id-kp-ntsServerAuthz object identifier.
      When a certificate issuer includes this object identifier in the
      extended key usage extension, it provides an attestation that the
      certificate subject is a time server which the issuer believes to be
      willing and able to disseminate correct time (for example, this can be
      used to signal a server's authorization to disseminate legal time).</t>

      <t>For a certificate issued to a time client, the Extended Key Usage
      extension MAY include the id-kp-ntsClientAuthz object identifier. When a
      certificate issuer includes this object identifier in the extended key
      usage extension, it provides an attestation that the certificate subject
      is a time client who has authorization from the issuer to access secured
      time synchronization (for example, this can be used to provide access in
      the case of a paid service for secure time synchronization).</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section title="SMI Security for S/MIME Module Identifier Registry">
        <t>Within the "SMI Security for S/MIME Module Identifier
        (1.2.840.113549.1.9.16.0)" table, add one module identifier:</t>

        <figure>
          <artwork><![CDATA[      Decimal  Description                             References
      -------  --------------------------------------  ----------
      TBD0     id-networkTimeSecurity-2015             [this doc]]]></artwork>
        </figure>
      </section>

      <section title="SMI Security for S/MIME CMS Content Type Registry">
        <t>Within the "SMI Security for S/MIME CMS Content Type
        (1.2.840.113549.1.9.16.1)" table, add thirteen content type
        identifiers:</t>

        <figure>
          <artwork><![CDATA[      Decimal  Description                             References
      -------  --------------------------------------  ----------
      TBD1     id-ct-nts-clientAccess                  [this doc]
      TBD2     id-ct-nts-serverAccess                  [this doc]
      TBD3     id-ct-nts-clientAssoc                   [this doc]
      TBD4     id-ct-nts-serverAssoc                   [this doc]
      TBD5     id-ct-nts-clientCookie                  [this doc]
      TBD6     id-ct-nts-serverCookie                  [this doc]
      TBD7     id-ct-nts-securityDataReq               [this doc]
      TBD8     id-ct-nts-securityDataResp              [this doc]
      TBD9     id-ct-nts-broadcastParamReq             [this doc]
      TBD10    id-ct-nts-broadcastParamResp            [this doc]
      TBD11    id-ct-nts-broadcastTime                 [this doc]
      TBD12    id-ct-nts-clientKeyCheck                [this doc]
      TBD13    id-ct-nts-serverKeyCheck                [this doc]]]></artwork>
        </figure>
      </section>

      <section title="SMI Security for PKIX Extended Key Purpose Registry">
        <t>Within the "SMI Security for PKIX Extended Key Purpose Identifiers
        (1.3.6.1.5.5.7.3)" table, add three key purpose identifiers:</t>

        <figure>
          <artwork><![CDATA[      Decimal  Description                             References
      -------  --------------------------------------  ----------
      TBD14    id-kp-ntsServerAuth                     [this doc]
      TBD15    id-kp-ntsServerAuthz                    [this doc]
      TBD16    id-kp-ntsClientAuthz                    [this doc]]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>For authentication the server's certificate MAY contain an extended
      key purpose identifier (id-kp-ntsServerAuth). Additionally the
      identifiers id-kp-ntsServerAuthz and id-kp-ntsClientAuthz MAY be used to
      grant the associated roles to the certified entity in the time
      dissemination infrastructure (see also Appendix D in <xref
      target="I-D.ietf-ntp-network-time-security"/>).</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Harlan Stenn, Richard Welty and
      Martin Langer for their technical review and specific text contributions
      to this document.</t>
    </section>
  </middle>

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

      <reference anchor="ASN1">
        <front>
          <title abbrev="ITU-T Recommendation X.680">Abstract Syntax Notation
          One (ASN.1): Specification of basic notation</title>

          <author fullname="International Telecommunication Union">
            <organization>International Telecommunication Union</organization>
          </author>

          <date month="November" year="2008"/>
        </front>

        <seriesInfo name="ITU-T Recommendation" value="X.680"/>
      </reference>

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

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

    <references title="Informative References">
      <?rfc include='reference.I-D.draft-ietf-ntp-network-time-security-13'?>

      <reference anchor="IEEE1588">
        <front>
          <title>IEEE standard for a precision clock synchronization protocol
          for networked measurement and control systems</title>

          <author fullname="IEEE Instrumentation and Measurement Society TC-9 Sensor Technology">
            <organization>IEEE Instrumentation and Measurement Society. TC-9
            Sensor Technology</organization>
          </author>

          <date year="2008"/>
        </front>
      </reference>

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

    <section title="ASN.1 Module">
      <t>The ASN.1 module contained in this appendix defines the id-kp-
      NTSserver object identifier.</t>

      <figure>
        <artwork><![CDATA[   NTSserverKeyPurpose
     { TBD }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   id-kp-NTSserver OBJECT IDENTIFIER ::= { TBD17 }

   END]]></artwork>
      </figure>
    </section>
  </back>
</rfc>
