[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 02

NTP Working Group                                              D. Sibold
Internet-Draft                                                       PTB
Obsoletes: 5906 (if approved)                                S. Roettger
Intended status: Standards Track                                   TU-BS
Expires: January 29, 2013                                  July 30, 2012

         Network Time Protocol: autokey Version 2 Specification
                        draft-sibold-autokey-00

Abstract

   This document describes a security protocol that enables
   authenticated time synchronization using Network Time Protocol (NTP).
   Autokey Version 2 obsoletes NTP autokey protocol (RFC 5906) which
   suffers from various security vulnerabilities.  Its design considers
   the special requirements that are related to the task of precise
   timekeeping.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 29, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.








Sibold & Roettger       Expires January 29, 2013                [Page 1]


Internet-Draft                                                 July 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Differences from the original autokey  . . . . . . . . . .  3
   2.  Security Threats . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Terms and abbreviations  . . . . . . . . . . . . . . . . . . .  4
   5.  Autokey Overview . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Protocol Sequence  . . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  Association Message  . . . . . . . . . . . . . . . . . . .  5
     6.2.  Certificate Message  . . . . . . . . . . . . . . . . . . .  5
     6.3.  Cookie Message . . . . . . . . . . . . . . . . . . . . . .  6
     6.4.  Time request message . . . . . . . . . . . . . . . . . . .  6
   7.  Hash and MAC algorithms  . . . . . . . . . . . . . . . . . . .  6
     7.1.  Hash Function for Cookie and Autokey . . . . . . . . . . .  6
     7.2.  Hash Function for the Message Authentication Code  . . . .  6
   8.  Server Seed Considerations . . . . . . . . . . . . . . . . . .  6
     8.1.  Server Seed Function . . . . . . . . . . . . . . . . . . .  6
     8.2.  Server Seed Live Time  . . . . . . . . . . . . . . . . . .  6
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  7
     12.2.  Informative References  . . . . . . . . . . . . . . . . .  8
   Appendix A. TICTOC Security Requirements . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9

1.  Introduction

   In NTP [RFC5905] the autokey protocol [RFC5906] was introduced to
   provide authenticity to NTP servers and to ensure integrity of time
   synchronization.  It is designed to meet the specific communication
   requirements of precise timekeeping.  Its basic design is a
   combination of PKI and a pseudo-random sequence of symmetric keys,
   the so-called autokeys of which each are valid for one packet only.
   This design maintains the stateless nature of NTP and therefore does
   not compromise timekeeping precision.







Sibold & Roettger       Expires January 29, 2013                [Page 2]


Internet-Draft                                                 July 2012


   This document focuses on a new definition of the autokey protocol for
   NTP, autokey version 2. The necessity to renew the autokey
   specification arises from various severe security vulnerabilities
   that have been found in a thorough analysis of the protocol
   [Roettger].  The new specification is based on the same assumptions
   as the original autokey specification.  In particular, the
   prerequisite is that precise timekeeping can only be accomplished
   with stateless time synchronization communication, which excludes
   standard security protocols like IPSec or TLS. This prerequisite
   corresponds with the requirement that a security mechanism for
   timekeeping must be designed in such a way that it does not degrade
   the quality of the time transfer [I-D.ietf-tictoc-security-
   requirements].

1.1.  Differences from the original autokey

   Autokey version 2 is a major redraft of the original autokey
   specification.  It is intended to mitigate security vulnerabilities
   of the original specification and it is based on the suggestions in
   the analysis of Roettger [Roettger].  The major changes are:

   o  The bit length of server seed and cookie has been increased.

   o  The utilized hash algorithms are negotiable.

   o  The IP addresses of the synchronization partners in the
      calculation of the cookie have been replaced by the public key of
      the NTP client.

   o  The identity schemes for the verification of the NTP server
      authenticity have been replaced by a hierarchical public key
      infrastructure (PKI) based on X.509 certificates.

   o  Compatibility with the current autokey specification is not given.

   o  The term proventication is not used, i.e., authorization and time
      synchronization are disentangled.

         Discussion

            The client verifies the authenticity of the server via PKI
            infrastructure.  To this end, it has to verify the
            certification chain up to a trusted authority which, in the
            context of the PKI, is a certification authority (CA).
            Proventication may be established if the trusted authority
            is also the NTP stratum 1 server.  See also the discussion
            in Section 6.2.

2.  Security Threats

   A profound analysis of security threats and requirements for NTP and
   Precision Time Protocol (PTP) can be found in the I-D [I-D.ietf-


Sibold & Roettger       Expires January 29, 2013                [Page 3]


Internet-Draft                                                 July 2012

   tictoc-security-requirements].

3.  Objectives

   The objectives of the autokey specifications are as follows:

   o  Authenticity: Autokey enables the client to authenticate its NTP
      server or peer.

   o  Integrity: Autokey protects the integrity of time synchronization
      packets via a message authentication code (MAC) or a hash-based
      message authentication code (HMAC).

   o  Confidentiality: Autokey does not provide confidentiality
      protection of the NTP packets.

   o  Modes of operation: All operational modes of NTP are supported
      (Client-Server, symmetric, broadcast).

   o  Hybrid mode: Both secure and insecure communication modes are
      possible for NTP servers and clients, respectively.

   o  Compatibility: Interoperation with autokey version 1 and the
      symmetric key scheme described in [RFC1305] is not given.
      Insecure NTP associations are not affected.

   o  Leap seconds are not in the scope of autokey.

4.  Terms and abbreviations

   o  Throughout this document the term "autokey" refers to autokey
      version 2.

5.  Autokey Overview

   In autokey, authenticity and integrity of NTP packets are ensured by
   an attached key ID and a message authentication code (MAC). The MAC
   is calculated with a so-called "autokey" which is a symmetric key
   that is valid for one packet only.  The MAC is given by

      MAC = H(autokey || NTP packet),

   where || indicates concatenation and in which H is a hash algorithm
   on which client and server agree during the association message
   (ASSOC) exchange.  The key ID uniquely identifies the autokey.  The
   autokeys are calculated for each NTP packet according to:

      autokey = H(key ID || cookie),

   in which H is a hash function on which client and server have to
   agree (during ASSOC) and which is not necessarily identical to the
   one used for the MAC calculation.  The cookie is a 128 bit secret



Sibold & Roettger       Expires January 29, 2013                [Page 4]


Internet-Draft                                                 July 2012

   between client and server.  It is exchanged during the cookie message
   protocol sequence (COOK). The cookie is calculated by the server via

      cookie = MSB_128 (H(server seed || public key of client)).

   The same hash algorithm H is utilized as in the calculation of the
   autokey.  The function MSB_128 cuts off the 128 most significant bits
   of the result of the hash function.  The server seed is a 128 bit
   random value of the server, which has to be kept secret.  The cookie
   thus never changes.  To comply with 4.5.3 in [I-D.ietf-tictoc-
   security-requirements] the server seed has to be changed
   periodically.  The server does not keep a state of the client.
   Therefore it has to recalculate the cookie each time it receives a
   request from the client.  To this end, the client has to attach its
   public key to each request (see Section 6.4).

   Discussion

      Alternative cookie calculation: Instead of using the client's
      public key for the cookie calculation, the hash value of the
      public key can be used.  This has the advantage that during the
      time request message the client only needs to send the hash of its
      public key and not the whole public key itself.

6.  Protocol Sequence

6.1.  Association Message

   The protocol sequence starts with the association message, in which
   the client sends an NTP packet with an extension field of type
   association.  It contains the hostname of the client and a status
   word which contains the algorithms used for the signatures and the
   status of the connection.  The response contains the hostname of the
   server and the algorithms for the signatures.  Client and server MUST
   agree upon the employed MAC and hash algorithms.

6.2.  Certificate Message

   In this step, the client receives the certification chain up to the
   trusted authority (TA). To this end, the client requests the
   certificate for the subject name (hostname) of the NTP server.  The
   response contains the certificate with the issuer name.  If the
   issuer name is different from the subject name, the client requests
   the certificate for the issuer.  This continues until it receives a
   certificate which is issued by a TA. The client recognizes the TA
   because it has a list of certificates which are accepted as TAs.  The
   client has to prove that each issuer is authorized to issue new
   certificates.  To this end, it has to prove that the X.509v3
   extension contains the field "CA:TRUE".  With the established
   certification chain the client is able to verify the server
   signatures and, hence, the authenticity of the server messages with
   extension fields is ensured.

   Discussion

Sibold & Roettger       Expires January 29, 2013                [Page 5]


Internet-Draft                                                 July 2012


      Note that this certification chain is a priori independent of the
      time synchronization chain, because the TA and the NTP root are
      not inevitably identical.  This has consequences if proventication
      is required (Requirement 4.1.2 in [I-D.ietf-tictoc-security-
      requirements]). In this case, proventication can be ensured only
      if the NTP root server is also a recognized TA, hence a CA.

6.3.  Cookie Message

   The client requests a cookie from the server, which is used to
   calculate the autokeys.  The request includes the public key of the
   client.  The public key is used by the server to calculate the
   cookie.  The response of the server contains the cookie encrypted
   with the public key.

6.4.  Time request message

   The client request includes a new extension field "time request"
   which contains its public key.  The server needs the public key to
   recalculate the cookie for the client.  The response is a normal NTP
   packet without extension field.

7.  Hash and MAC algorithms

   Hash algorithms are used for the calculation of cookie, autokey and
   MAC.

7.1.  Hash Function for Cookie and Autokey

   The hash algorithm utilized for the calculation of the cookie and the
   autokey is negotiated during the association message exchange
   (Section 6.1). The client MUST request SHA-1 or a stronger hash
   function.  The server also MUST provide SHA-256.

7.2.  Hash Function for the Message Authentication Code

   The hash function for the MAC is negotiated during the association
   message exchange in Section 6.1. Client and server SHOULD negotiate a
   Keyed-Hash Message Authentication Code [RFC2104].

8.  Server Seed Considerations

   The server has to calculate a random seed which has to be kepted
   secret and which has to be changed periodically.

8.1.  Server Seed Function

8.2.  Server Seed Live Time

9.  IANA Considerations

   This document makes no request of IANA.


Sibold & Roettger       Expires January 29, 2013                [Page 6]


Internet-Draft                                                 July 2012


   Note to RFC Editor: this section may be removed on publication as an
   RFC.

10.  Security Considerations

   The client has to verify the validity of the certificates during the
   certification message exchange (Section 6.2). Since it generally has
   no reliable time during this initial communication phase, it is
   impossible to verify the period of validity of the certificates.
   Therefore, the client MUST use one of the following approaches:

   o  The TA and the dependent certificates are trusted by default.
      Usually this will be the case in corporation networks.

   o  The client ensures that the certificates are not revoked.  To this
      end, the client uses the Online Certificate Status Protocol (OCSP)
      defined in [RFC6277].

   o  The client requests a different service to get an initial time
      stamp in order to be able to verify the certificates' periods of
      validity.  To this end, it can, e.g., use a secure shell
      connection to a reliable host.  Another alternative is to request
      a time stamp from a Time Stamping Authority (TSA) by means of the
      Time-Stamp Protocol (TSP) defined in [RFC3161].

11.  Acknowledgements

12.  References

12.1.  Normative References

   [I-D.ietf-tictoc-security-requirements]
              Mizrahi, T. and K. O'Donoghue, "TICTOC Security
              Requirements", Internet-Draft draft-ietf-tictoc-security-
              requirements-02, June 2012.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

   [RFC5905]  Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

Sibold & Roettger       Expires January 29, 2013                [Page 7]


Internet-Draft                                                 July 2012


   [RFC5906]  Haberman, B. and D. Mills, "Network Time Protocol Version
              4: Autokey Specification", RFC 5906, June 2010.

   [RFC6277]  Santesson, S. and P. Hallam-Baker, "Online Certificate
              Status Protocol Algorithm Agility", RFC 6277, June 2011.

12.2.  Informative References

   [Roettger]
              Roettger, S., "Analysis of the NTP Autokey Procedures",
              February 2012.

Appendix A.  TICTOC Security Requirements

   The following table compares the autokey specifications against the
   tictoc security requirements [I-D.ietf-tictoc-security-requirements].

   +-----------+----------------------------------+--------+-----------+
   | Section   | Requirement from I-D tictoc      | Type   | Autokey   |
   |           | security-requirements-02         |        | V2        |
   +-----------+----------------------------------+--------+-----------+
   | 4.1       | Authentication of sender.        | MUST   | OK        |
   |           | Authentication of master.        | MUST   | OK        |
   |           | Proventication                   | MUST   | Open 1)   |
   |           | Authentication of slaves.        | SHOULD | OK        |
   |           | PTP: Authentication of TCs.      | SHOULD | N/A       |
   |           | PTP: Authentication of Announce  | SHOULD | N/A       |
   |           | messages.                        |        |           |
   | 4.2       | Integrity protection.            | MUST   | OK        |
   |           | PTP: hop-by-hop integrity        | MUST   | N/A       |
   |           | protection.                      |        |           |
   |           | PTP: end-to-end integrity        | SHOULD | N/A       |
   |           | protection.                      |        |           |
   | 4.3       | Protection against DoS attacks.  | MUST   | NTP 2)    |
   | 4.4       | Replay protection.               | MUST   | NTP 2)    |
   | 4.5       | Security association.            | MUST   | OK        |
   |           | Unicast and multicast            | MUST   | OK        |
   |           | associations.                    |        |           |
   |           | Key freshness.                   | MUST   | OK        |
   | 4.6       | Performance: no degradation in   | MUST   | OK        |
   |           | quality of time transfer.        |        |           |
   |           | Performance: lightweight.        | SHOULD | YES       |
   |           | Performance: storage, bandwidth. | MUST   | OK        |
   | 4.7       | Confidentiality protection.      | MAY    | NO        |
   |           | Protection against delay         | MAY    | NO        |
   |           | attacks.                         |        |           |
   | 4.9       | Secure mode.                     | MUST   | NTP? 3)   |
   |           | Hybrid mode.                     | MAY    | YES       |
   +-----------+----------------------------------+--------+-----------+

     1) Refer to discussion in Section 6.2. 2) These requirements are
    fulfilled by the NTP on-wire protocol.  3) Has still to be checked.


Sibold & Roettger       Expires January 29, 2013                [Page 8]


Internet-Draft                                                 July 2012


Authors' Addresses

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

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


   Stephen Roettger
   Technische Universitaet Braunschweig

   Email: stephen.roettger@googlemail.com





































Sibold & Roettger       Expires January 29, 2013                [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/