Internet DRAFT - draft-navas-ace-secure-time-synchronization

draft-navas-ace-secure-time-synchronization







ACE Working Group                                               R. Navas
Internet-Draft                                          Telecom Bretagne
Intended status: Standards Track                             G. Selander
Expires: May 4, 2017                                         Ericsson AB
                                                                L. Seitz
                                                        SICS Swedish ICT
                                                        October 31, 2016


     Lightweight Authenticated Time (LATe) Synchronization Protocol
             draft-navas-ace-secure-time-synchronization-00

Abstract

   This documents defines the Lightweight Authenticated Time (LATe)
   Synchronization Protocol, a secure time synchronization protocol for
   constrained environments.  The messages are encoded using Concise
   Binary Object Representation (CBOR) and basic security services are
   provided by CBOR Object Signing and Encryption (COSE).  A secure
   source of time is a base assumption for many other services,
   including security services.  LATe Synchronization protocol enables
   these time-dependent services to run in the context of a constrained
   environment.

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 May 4, 2017.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Navas, et al.              Expires May 4, 2017                  [Page 1]

Internet-Draft        LATe Synchronization Protocol         October 2016


   (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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Goals, Actors and Assumptions  . . . . . . . . . . .   4
   3.  Base Protocol . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Message Exchanges and Semantics . . . . . . . . . . . . .   5
     3.2.  Time Synchronization Calculation  . . . . . . . . . . . .   6
   4.  Message Encodings . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  CBOR TIC and MSG1: Time Request . . . . . . . . . . . . .   7
     4.2.  CBOR TOC and MSG2: Time Representation Response . . . . .   9
   5.  Protocol Triggering . . . . . . . . . . . . . . . . . . . . .  10
   6.  Protocol on ACE Framework . . . . . . . . . . . . . . . . . .  11
     6.1.  Actors Mappings . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Possible Scenarios  . . . . . . . . . . . . . . . . . . .  11
     6.3.  Solution For Scenario 1.1 . . . . . . . . . . . . . . . .  12
     6.4.  Solution For Scenario 1.2 . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Authentication and Authorization for Constrained Environments (ACE)
   working group defined a framework for authentication and
   authorization in Internet of Things (IoT) environments: the ACE
   framework [I-D.ietf-ace-oauth-authz].  Many security services offered
   rely on measuring time in constrained devices, for determining
   validity of access tokens and freshness of requests.  While clocks
   are affordable in many settings, and energy consumption may be less
   than intrinsic battery discharge, there is a need for synchronization
   of time between the nodes.

   We propose a secure time synchronization protocol in the context of
   the ACE framework, where the time server is the Authorization Server.



Navas, et al.              Expires May 4, 2017                  [Page 2]

Internet-Draft        LATe Synchronization Protocol         October 2016


1.1.  Terminology

   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 [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.

   Security terminology such as "nonce", "fresh", "random number
   generator", is defined in [RFC4949].

   Terminology for constrained environments, such as "constrained
   device", "constrained-node network", is defined in [RFC7228].

   A "Real-time clock" (RTC) is a computer clock that keeps track of the
   current time, with low power consumption and using an alternate
   source of power.

   Readers are expected to be familiar with the terms and concepts
   described in [I-D.ietf-ace-actors] and [I-D.ietf-ace-oauth-authz].

1.2.  Motivation

   Authentication and Authorization for Constrained Environments (ACE)
   framework is specified on [I-D.ietf-ace-oauth-authz].  The solution
   relies on OAuth 2.0 framework and on OAuth 2.0 Proof-of-possession
   tokens [I-D.ietf-oauth-pop-architecture].  The framework's security
   services rely on token validation and expiration.  In order to
   validate a token (aside from a token introspection solution) the
   Resource Server needs to have an internal time representation
   synchronized with the Authorization Server.  In order achieve that, a
   secure time synchronization mechanism must be implemented.  Solutions
   such as (Simple) Network Time Protocol (S)NTP Version 4 [RFC5905],
   widely used on the standard internet, falls short in the constrained
   setting for several reasons.  The fundamental reason is that it does
   not achieve a secure and fresh source of time even running in the
   authenticated mode, this shortcoming is explained on the "Security
   Considerations" section of NTPv4:

      "The lifetime of cryptographic values must be enforced, which
      requires a reliable system clock.  However, the sources that
      synchronize the system clock must be trusted.  This circular
      interdependence of the timekeeping and authentication functions
      requires special handling."

   To break this circular dependence an hypothesis ("leap of faith") can
   be made: the end-to-end communicating parties have valid pre-shared
   cryptographic material.  In the constrained environment setting, this



Navas, et al.              Expires May 4, 2017                  [Page 3]

Internet-Draft        LATe Synchronization Protocol         October 2016


   seems like a reasonable assumption e.g., nodes deployed with a pre-
   shared key (PSK) with a trusted-third-party.  If the source of time
   then is trusted, then the fundamental security problem to solve is to
   assure the freshness of a transaction.  The freshness problem can be
   solved with an appropriate use of 'nonces' within the protocol.

   A comprehensive document about time protocol security requirements
   can be found on "Security Requirements of Time Protocols in Packet
   Switched Networks" [RFC7384].

   Current efforts to provide a solution to the secure time problem
   includes the work-in-progress "Network Time Security (NTS)"
   [I-D.ietf-ntp-network-time-security] which provides mechanisms to
   secure an existing time protocol.  NTS is not constrained-environment
   friendly.  In order to establish a basic time synchronization
   exchange, six messages should be exchanged (Association Exchange,
   Cookie Exchange, and finally unicast time synchronization).
   Furthermore current time protocols such as (S)NTPv4 are not designed
   for constrained environments either.  The combination of both such as
   in "NTS for NTPv4 using Cryptographic Message Syntax (CMS)"
   [I-D.ietf-ntp-cms-for-nts-message] is certainly not suited for the
   ACE Scenario.

   This documents defines the "Lightweight Authenticated Time (LATe)
   Synchronization Protocol", which provides a secure time
   synchronization protocol suited for constrained environments.  Using
   this protocol on top of the ACE framework is one of the design goals.

2.  Protocol Goals, Actors and Assumptions

   Functional Goal:

   o  The protocol enables a constrained node to obtain a local time
      representation from a trusted entity, with an associated +/-
      uncertainty.

   Security Goals:

   o  Authentication: The time representation must be authenticated
      (data authentication).

   o  Freshness: The time representation must be fresh (See: [RFC4949]).

   Actors:

   o  Time Client (TC): The entity that attempts to update its local
      time representation.




Navas, et al.              Expires May 4, 2017                  [Page 4]

Internet-Draft        LATe Synchronization Protocol         October 2016


   o  Time Server (TS): The entity that provides its local time
      representation.

   Assumptions:

   o  TC and TS MUST have valid pre-shared cryptographic material.  For
      symmetric cryptography the key MUST be shared only by TC and TS,
      no third party.  For the rest of this document symmetric key
      cryptography is assumed.

   o  The protocol messages are transported over unsecure communication
      channels.  A datagram channel is assumed.

   o  TC MUST have self-powered relative time-awareness capabilities,
      i.e., a Real-Time Clock.  If not self-powered, a reboot of the
      node can be a security breach.

   o  The time-sensitive application that uses this protocol MUST
      tolerate a time uncertainty of at least half the round-trip time
      (RTT) measured from TC to TS (e.g., if RTT is 6 seconds, then time
      uncertainty tolerated must be greater than +/- 3 seconds).

3.  Base Protocol

   This section describes the base time synchronization protocol for
   constrained environments.  This protocol is designed to be embedded
   on the ACE framework [I-D.ietf-ace-oauth-authz], this is detailed on
   Section 6.

   This base-protocol-first approach permits an easier understanding and
   scrutiny of the protocol and the goals it claims to achieve from a
   functional and security point of view.  A flaw on the base protocol
   implies a flaw on the embedded-on-ACE protocol.

3.1.  Message Exchanges and Semantics

   The protocol consists of two messages that are represented on
   Figure 1.













Navas, et al.              Expires May 4, 2017                  [Page 5]

Internet-Draft        LATe Synchronization Protocol         October 2016


            Time Server                           Time Client
                 +                                    +
                 |                                    |
                 |                                    |
                 |          Nonce_TC,Key-ID           |
                 <------------------------------------+ (MSG1)
                 |                                    |
                 |                                    |
                 |                                    |
                 |         Nonce_TC,TS_Time           |
                 +------------------------------------> (MSG2)
                 |  Authentication(Nonce_TC,TS_Time)  |
                 |                                    |
                 |                                    |


                          Figure 1: Base Protocol

   MSG1: From TC to TS.  Contains:

   o  A nonce generated by TC (Nonce_TC).  The nonce MUST be at least
      64-bits and random (A pseudo-random number generator can be used
      if the seed value has sufficient entropy).

   o  A Key-Id (opaque) to indicate to TS which cryptographic Key to use
      to authenticate the response.

   MSG2: From TS to TC.  Contains:

   o  The same nonce received on MSG1 (Nonce_TC)

   o  The local time representation of TS (TS_Time)

   o  Authentication information (e.g., a MAC) for the message
      (Nonce_TC,TS_Time), i.e., an authentication "tag".

3.2.  Time Synchronization Calculation

   The Time Client will have to run the following Algorithm to achieve
   authenticated time synchronization:

   1.  TC Internally timestamps when it sends MSG1 (T1).

   2.  TC Authenticates MSG2 (Contains: Nonce_TC and Time_TS).

   3.  TC Verifies nonce on MSG2 matches Nonce_TC sent on MSG1.





Navas, et al.              Expires May 4, 2017                  [Page 6]

Internet-Draft        LATe Synchronization Protocol         October 2016


   4.  TC Calculates RTT = (TC_Current - T1), and verifies that RTT is
       within the acceptable range.

   5.  TC set his internal clock Time_TC = Time_TS + (RTT/2).

   NOTE:  TC does not send any message to TS after receiving MSG2,
      neither in case of success or failure.

4.  Message Encodings

   The messages are encoded in CBOR [RFC7049].  CBOR Object Signing and
   Encryption (COSE) [I-D.ietf-cose-msg] is used to cryptographically
   protect the message.  This protocol will define and use two new CBOR
   objects: 'TIC Information' and 'TOC Response'.

   The ACE framework uses CoAP [RFC7252] as application protocol and
   this protocol also assumes CoAP to transport the CBOR messages.  CoAP
   options "Uri-Path" and "Content-Format" are used to identify a run of
   this protocol.  The protocol, however, is designed to be as
   independent as possible on the underlying layers to facilitate its
   use on top of any other datagram oriented mechanism with application
   multiplexing or to be nested inside other CBOR/COSE objects.

4.1.  CBOR TIC and MSG1: Time Request

   The Time Request is sent from the Time Client to the Time Server.
   The Time Request message will be a CoAP POST to the "/time" resource
   of TS (Content-Type: "application/late+cbor; late-type=tic").  The
   CoAP payload will contain a new CBOR Map 'TIC Information' object as
   defined on Table 1.





















Navas, et al.              Expires May 4, 2017                  [Page 7]

Internet-Draft        LATe Synchronization Protocol         October 2016


   +------------+-------+-------+-----------+--------------------------+
   | Parameter  |  CBOR | Value | registry  | description              |
   | name       |  Key  | Type  |           |                          |
   +------------+-------+-------+-----------+--------------------------+
   | nonce      |   4   | bstr  |           | A random nonce           |
   |            | (TBD) |       |           |                          |
   |            |       |       |           |                          |
   | kid        |   5   | bstr  |           | Key-ID is an opaque      |
   |            | (TBD) |       |           | value and identifies the |
   |            |       |       |           | cryptographic key to be  |
   |            |       |       |           | used in the response     |
   |            |       |       |           |                          |
   | alg        |   6   | int   | COSE      | Identifies the           |
   | (optional) | (TBD) |       | Algorithm | cryptographic algorithm  |
   |            |       |       | Values    | to be used in the        |
   |            |       |       |           | response                 |
   |            |       |       |           |                          |
   | server     |   7   | tstr  |           | Identifies the intended  |
   | (optional) | (TBD) |       |           | Server for time          |
   |            |       |       |           | synchronization          |
   |            |       |       |           | (Absolute-URI)           |
   +------------+-------+-------+-----------+--------------------------+

           Table 1: CBOR Map 'TIC Information' object definition

   A Time Request (MSG 1) message example is shown in Figure 2 using
   CBOR diagnostic notation.

   Header: POST (Code=0.02)
   Uri-Host: "server.org"
   Uri-Path: "time"
   Content-Format: "application/late+cbor; late-type=tic"
   Payload:
   {
    nonce : h'73616e206c6f7265',
    kid   : h'0001',
    alg   : 4 /* HMAC w/ SHA-256 truncated to 64 bits */
   }

            Figure 2: MSG1 example in CBOR diagnostic notation

   Figure 3 illustrates the binary encoding (17 Bytes) of the CoAP
   payload (i.e., CBOR TIC) shown in Figure 2.








Navas, et al.              Expires May 4, 2017                  [Page 8]

Internet-Draft        LATe Synchronization Protocol         October 2016


   a3                                     # map(3)
      04                                  # unsigned(4) (=nonce)
      50                                  # bytes(8)
         73616e206c6f7265                 #
      05                                  # unsigned(5) (=kid)
      42                                  # bytes(2)
         0001                             #
      06                                  # unsigned(6) (=alg)
      04                                  # unsigned(4)

     Figure 3: MSG1 Payload: 'TIC Information' CBOR object (17 Bytes)

4.2.  CBOR TOC and MSG2: Time Representation Response

   The Time Representation response message is sent from the Time Server
   to the Time Client.  The CoAP Content-Type will be set to
   "application/late+cose;cose-type=cose-mac; late-type=toc".  The
   message will contain the Nonce received on the Time Request ('nonce')
   and the Time Representation of the Time Server ('time') (TBD how to
   represent time).  The 'nonce' and 'time' information will be encoded
   using a CBOR Map object 'TOC Response' as defined on Table 2.

   +---------------+---------+-----------+-----------------------------+
   | Parameter     | CBOR    | Value     | description                 |
   | name          | Key     | Type      |                             |
   +---------------+---------+-----------+-----------------------------+
   | time          | 3 (TBD) | uint      | A time representation       |
   |               |         | (TBD)     | information                 |
   |               |         |           |                             |
   | nonce         | 4 (TBD) | bstr      | A random nonce              |
   +---------------+---------+-----------+-----------------------------+

            Table 2: CBOR Map 'TOC Response' object definition

   The 'TOC Response' object MUST be authenticated using the key ('kid')
   and algorithm ('alg', if present) specified on the Time Request.
   This authenticated message will be encoded using a COSE_Mac0
   structure.

   The 'TOC Response' MUST be placed on the 'payload' part of the
   COSE_Mac0 stucture.  If 'alg' was present on the Time Request it MUST
   be placed on the 'protected' header of the Response, if 'alg' was not
   present on the Time Request it MUST NOT be present on the Response.
   ('kid' TBD) The 'kid' MUST be either: placed on the 'protected'
   header, or supplied as 'external_aad' in the COSE MAC_structure to
   compute the mac.





Navas, et al.              Expires May 4, 2017                  [Page 9]

Internet-Draft        LATe Synchronization Protocol         October 2016


   An example of a Time Representation message is shown on Figure 4
   using non-normative CBOR diagnostic notation to make it easier to
   understand.

   Header: Changed (Code=2.04)
   Content-Type: "application/late+cose;
                  cose-type=cose-mac; late-type=toc"
   Payload:

   {
     protected  : {
                   kid: h'0001',
                   alg: 4 /* HMAC w/ SHA-256 truncated to 64 bits */
                   },
     payload    : {
                   time  : 1477307841,
                   nonce : h'73616e206c6f7265'
                   },
     tag        : h'36f5afaf0bab5d43'
   }

    Figure 4: MSG2 example COSE-MACed 'TOC Response' in CBOR diagnostic
                                 notation

   An implementation of this specification MUST implement the MAC
   algorithm "HMAC w/ SHA-256 truncated to 64 bits" as specified on
   [I-D.ietf-cose-msg].  The PSK used for HMAC MUST be at least 256-bits
   long.  Rationale: a CoAP implementation with DTLS on PSK mode
   requires the cipher suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655], which
   already includes HMAC with SHA-256.

5.  Protocol Triggering

   An important property of the protocol is when and how to trigger the
   execution of it.  While conditions for the trigger itself will be
   application-dependent, this section goal is to give useful general
   thoughts on the matter.

   There is a difference between the 'trigger' itself, that indicates
   that a time synchronization protocol must be run, and the actual
   execution of the protocol (e.g., it can be delayed).

   There can be two types of triggers:

   o  Internal Trigger: The Time Clients determines it needs to
      synchronize its time.  (Real-Time Clocks are needed to avoid
      possible attacks. e.g., reset node and force time sync.)




Navas, et al.              Expires May 4, 2017                 [Page 10]

Internet-Draft        LATe Synchronization Protocol         October 2016


   o  External Trigger: Other party determines that the Time Client
      needs to synchronize its time. (request must be authenticated and
      reply-protected or fresh)

   As for the protocol execution itself the following categories are
   defined:

   o  Active Time Synchronization:

      *  Time Client contacts Time Server directly (min 2 messages)

      *  Other Party initiates protocol (min 3 messages)

   o  Opportunistic/Passive Time Synchronization

      *  The protocol is initiated when the Time Client receives any
         message from a third-party.  The third-party (if supports the
         protocol) will be used as a relay from the Time Client to the
         Time Server.

6.  Protocol on ACE Framework

6.1.  Actors Mappings

   The Actors on this protocol will map on the ACE Framework as follows:

   o  The ACE Authorization Server (AS) is the Time Server

   o  The ACE Resource Server (RS) is the Time Client

   o  The ACE Client (C) will relay messages.

6.2.  Possible Scenarios

   We characterize the scenarios by the first messages on the
   interaction:

   1.  First Message C -> RS: Resource Request

       1.  Response: Time Synchronization only needed

       2.  Response: Time Synchronization + Access Token needed

   2.  First Message C -> AS: ACE Basic Protocol Flow

   3.  First Message RS -> AS: Direct Communication (RS Can do
       Introspection)




Navas, et al.              Expires May 4, 2017                 [Page 11]

Internet-Draft        LATe Synchronization Protocol         October 2016


   4.  TBD

6.3.  Solution For Scenario 1.1

   The First Message is from C to RS.  The Client sends a Resource
   Request to the RS (Time Client).  RS has internally triggered the
   need for time synchronization so opportunistically will initiate the
   LATe Synchronization Protocol by sending a TIC Information object.
   The message flow for this scenario is summarized on Figure 5.

       AS                 C                      RS
   (Time Server)          |                (Time Client)
       |                  |                      |
       |                  +------ Res. Req.----->+
       |                  |                      |
       |                  |                      |
       |                  +<-4.01 Unauthorized---+
       |                  |     (TIC Info)       |
       +<---LATe MSG1-----+                      |
       |                  |                      |
       |                  |                      |
       +----LATe MSG2---->+                      |
       |                  |                      |
       |                  +-------POST /time---->+ /time
       |                  |  (AUTH TOC Response) |
       |                  |                      |
       |                  +<----2.04 Changed-----+
       |                  |                      |
       +                  +                      +

                     Figure 5: LATe on ACE Scenario 1

   A detailed description of the message flows and contents goes as
   follows:

   1.  C to RS: Resource Request.

   2.  RS to C: RS responds with a CoAP response code 4.01
       (Unauthorized) containing a CBOR TIC Information object (Content-
       Type: "application/late+cbor; late-type=tic"), the TIC
       information MUST contain the time server (AS) Absolute-URI.

   3.  C to AS: C will act as a proxy and forward the "LATe MSG1" from
       the base protocol to AS using the TIC Information from RS.

   4.  AS to C: As will reply a "LATe MSG2" as specified on the base
       protocol.




Navas, et al.              Expires May 4, 2017                 [Page 12]

Internet-Draft        LATe Synchronization Protocol         October 2016


   5.  C will forward the payload from "LATe MSG2" without any
       modification, which consists of a COSE Authenticated TOC Response
       object, and send it as the payload of a CoAP POST to the "/time"
       resource on RS (Content-Type: "application/late+cose;cose-
       type=cose-mac; late-type=toc").

   6.  RS to C: Responds with the appropriate response code (e.g., "2.04
       Changed")(TBD do not reply)

   An example of messages 2 and 5 are shown on Figure 6 and Figure 7
   respectively.

   Header: 4.01 Unauthorized
   Content-Type: "application/late+cbor; late-type=tic"
   Payload:
   {
    server     : 'coap://server.org/time',
    nonce      : h'73616e206c6f7265',
    kid        : h'0001',
    alg        : 4 /* HMAC w/ SHA-256 truncated to 64 bits */
   }

       Figure 6: Unauthorized Response with a TIC Information object

   Header: POST (Code=0.02)
   Uri-Path: "time"
   Content-Type: "application/late+cose;
                  cose-type=cose-mac; late-type=toc"
   Payload:
   {
     protected  : {
                   kid: h'0001',
                   alg: 4 /* HMAC w/ SHA-256 truncated to 64 bits */
                   },
     payload    : {
                   time  : 1477307841,
                   nonce : h'73616e206c6f7265'
                   },
     tag        : h'36f5afaf0bab5d43'
   }

     Figure 7: CoaP POST /time of an Authenticated TOC Response object

6.4.  Solution For Scenario 1.2

   The First Message is from C to RS.  The Client sends a Resource
   Request to the RS (Time Client).  C does not yet have a secure
   association with RS.  ACE protocol will be triggered.  RS has



Navas, et al.              Expires May 4, 2017                 [Page 13]

Internet-Draft        LATe Synchronization Protocol         October 2016


   internally triggered the need for time synchronization so
   opportunistically will initiate the LATe Synchronization Protocol by
   sending a TIC Information object.  The message flow for this scenario
   is summarized on Figure 8.

       AS                 C                      RS
   (Time Server)          |                (Time Client)
       |                  |                      |
       |                  +--Unauthz.Res. Req.-->+ 1.
       |                  |                      |
       |                  |                      |
       |                  +<-4.01 Unauthorized---+ 2.
       |                  |   (ACE Info + TIC)   |
    3. +<---Token Request-+                      |
       |       + TIC      |                      |
       |                  |                      |
    4. +--Token Response->+                      |
       |     + AUTH TOC   |                      |
       |                  +---POST /authz-inf--->+ 5.
       |                  | (Token + AUTH TOC)   |
       |                  |                      |
       |                  +<----2.04 Changed-----+ 6.
       |                  |                      |
       +                  +                      +

                    Figure 8: LATe on ACE Scenario 1.2

   Message no. 2 is depicted on Figure 9.

   Header: 4.01 Unauthorized
   Content-Type: "application/ace+late+cbor; late-type=tic"
   Payload:
   {
    server     : 'coaps://as.org/token',
    nonce      : h'73616e206c6f7265',
    kid        : h'0001',
    alg        : 4 /* HMAC w/ SHA-256 truncated to 64 bits */
   }

      Figure 9: Unauthorized Response with a TIC Information object +
                      Initiation of the ACE Protocol

   o  Msg. 3.  Token Request: additional parameter 'tic' will contain
      the 'TIC Information object' from message 2.

   o  Msg. 4.  Token Response: additional parameter 'toc' will contain
      the COSE Authenticated 'TOC Response'.




Navas, et al.              Expires May 4, 2017                 [Page 14]

Internet-Draft        LATe Synchronization Protocol         October 2016


   o  Msg. 5.  Access Token POST: idem Token Response.

   Message no. 5 on Figure 10.

   Header: POST (Code=0.02)
   Uri-Path:"authz-info"
   Content-Format: "application/cwt+late; late-type=toc"
   Payload:
   {
    toc      : <COSE-MACed TOC Response>
    cwt      : <COSE-Encrypted CBOR Web Token>
   }

                 Figure 10: Possible message 5: CWT + TOC

7.  Security Considerations

   Security goals and concerns have guided the design of this protocol.
   The whole document has security recommendations and notes.  See
   Section 2 for the explicit security goals.  We summarize most of
   security-related information on this section, with the addition of
   some more considerations:

   o  This protocol security goals are information authentication
      (source-destination authentication) and freshness, as stated on
      Section 2.

      *  NOTE: An asymmetric-cryptography variant of this protocol only
         providing TS source authentication for MSG2 will be a weaker
         version subject to a much higher probability of successful
         attack; in that case MSG2 MUST be also confidentiality
         protected for TC; another solution is authenticate the ID of
         the intended recipient (TC-id, or use kid).

   o  Nonce generation: The nonce MUST be at least a 64-bit uniformly-
      distributed random number.  A pseudo-random number generator
      (PRNG) MAY be used if the seed value has sufficient entropy.  For
      detailed guidelines on randomness see [RFC4086].  About the length
      of the nonce: 64-bit-length will have a probability of collision
      around 2^-32 for 2^16 uses of the protocol, and 50% for 2^32 uses;
      depending on the application this may suffice.  Longer nonces MAY
      be used if 64-bit-lenght does not provide enough security in the
      estimated lifetime of the node-key (or estimated attacker
      capabilities).  See "birthday attack" [RFC4949].

      *  Discuss other lightweight alternatives for randomness:





Navas, et al.              Expires May 4, 2017                 [Page 15]

Internet-Draft        LATe Synchronization Protocol         October 2016


         +  (1) An incremental counter stored on non-volatile memory
            used as an input of a PRNG may be used (use of non-volatile
            memory comes with challenges itself e.g., no. of writes,
            tampering).

         +  (2) If MSG1 and MSG2 are authenticated and encrypted, a
            plaintext counter stored on non-volatile memory may be
            sufficient.

   o  About Real-Time Clocks (RTC): The Time Client MUST have a RTC.
      The protocol's possible attacks where not studied in case of TC
      not having a RTC Clock.  Also the Time Server MUST have a RTC, as
      it is the secure source of time (out of scope TS attacks).
      Surprisingly, non-constrained nodes (Class 2 [RFC7228]) such as
      Raspberry Pi or Arduino-Mega, which are often used as powerful
      nodes on constrained environments, do not have a RTC, making them
      constrained in the sense of time-awareness.  NOTE: An update of
      the RFC7228 (RFC7228-bis) will clarify the constraints in terms of
      time.

   o  An implementation of this specification MUST implement the MAC
      algorithm "HMAC w/ SHA-256 truncated to 64 bits" as specified on
      [I-D.ietf-cose-msg].  The protocol provides crypto-agility to use
      another algorithm in case the aforementioned gets compromised in
      the future.

   o  The PSK used for HMAC MUST be at least 256-bits long.  (For AES-
      CBC-MAC or AES-CMAC 128-bit PSK will suffice)

   o  The use of a dedicated PSK only for this time synchronization
      protocol is RECOMMENDED.  Use of the key for other purposes (e.g.:
      application data encryption) will increase the probability of the
      key being compromised or this protocol being broken.  The Time
      synchronization PSK, and other keys used by the node, can be
      securely derived from a Master-Key (this is out of scope)

   o  A stronger version of this protocol can be achieved by using
      authenticated and encrypted MSG1 and MSG2.  However this solution
      will require more resources at the Time Client (more encryption/
      decryption operations, and probably more bits-over-the-air to
      transmit -i.e., more energy-).  There is always a trade-off
      between resource-friendly and stronger security.  The current
      version of the protocol provides a lightweight solution yet
      providing the security goals from Section 2

   o  Time Server DoS Attack.  As MSG1 from the base protocol does not
      impose any security service, the Time Server (or Authorization
      Server) is highly exposed to DoS Attacks.  To mitigate this, and



Navas, et al.              Expires May 4, 2017                 [Page 16]

Internet-Draft        LATe Synchronization Protocol         October 2016


      at the same time decrease the probability of a successful attack
      to the protocol, we can Authenticate the MSG1 from the Time
      Client.  This mitigation is limited though, as an attacker with a
      valid MSG1 can replay it.  A Replay-protection mechanism should be
      used such as using authenticated IVs.  This replay-protection
      mitigation is out of scope, but it can rely on COSE messages
      secure properties.

   o  Time Client DoS Attack.  TC is exposed to DoS attacks.  To
      mitigate to the greatest extent possible rejection of MSG2 should
      be done on the least resource-consuming way.  No response might be
      given in case of success of failure of the protocol.  External
      triggering of the protocol must be also carefully secure
      (authenticated plus replay protection or fresh).

8.  Privacy Considerations

   The protocol sends the Time Server's time representation on
   plaintext.  It is only authenticated.  This might be an undesired
   privacy breach.  To completely mitigate this concern MSG2 of the base
   protocol must be authenticated and encrypted (AE).

   MSG1 of the base protocol needs, at minimum, to identify the
   cryptographic key that will have to be used on the response.
   Initially the TC's Identity (e.g, URI) was pondered as a solution (in
   fact, TC's ID may be known to the party interacting with it).  But
   unique and static identification information is on the opposite
   direction of privacy goals.  Hence a trade-off has to be made, and we
   chose the minimum identification required to run the protocol, that
   is to send an opaque key-id.  Key-id is static in this protocol,
   which can be used for fingerprinting, but a method to change it
   dynamically can exist (out of scope).  Any other opaque, or dynamic,
   identifier may be used, still guaranteeing an appropriate level of
   privacy.  Entity-ID, Resource-ID, Security Association ID, IDs in
   general and Privacy is a topic yet to be properly studied on the ACE
   context.

9.  IANA Considerations

   TBD

10.  References

10.1.  Normative References







Navas, et al.              Expires May 4, 2017                 [Page 17]

Internet-Draft        LATe Synchronization Protocol         October 2016


   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-oauth-
              authz-04 (work in progress), October 2016.

   [I-D.ietf-cose-msg]
              Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-23 (work in progress), October 2016.

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

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

10.2.  Informative References

   [I-D.ietf-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-04 (work in
              progress), September 2016.

   [I-D.ietf-ntp-cms-for-nts-message]
              Sibold, D., Teichel, K., Roettger, S., and R. Housley,
              "Protecting Network Time Security Messages with the
              Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
              for-nts-message-06 (work in progress), February 2016.

   [I-D.ietf-ntp-network-time-security]
              Sibold, D., Roettger, S., and K. Teichel, "Network Time
              Security", draft-ietf-ntp-network-time-security-15 (work
              in progress), September 2016.

   [I-D.ietf-oauth-pop-architecture]
              Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
              Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
              Architecture", draft-ietf-oauth-pop-architecture-08 (work
              in progress), July 2016.



Navas, et al.              Expires May 4, 2017                 [Page 18]

Internet-Draft        LATe Synchronization Protocol         October 2016


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

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <http://www.rfc-editor.org/info/rfc4949>.

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

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655,
              DOI 10.17487/RFC6655, July 2012,
              <http://www.rfc-editor.org/info/rfc6655>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

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

Authors' Addresses

   Renzo Navas
   Telecom Bretagne
   2 rue de la Chataigneraie
   Cesson-Sevigne  35510
   France

   Email: renzo.navas@telecom-bretagne.eu


   Goeran Selander
   Ericsson AB
   Farogatan 6
   Kista  SE-16480 Stockholm
   Sweden

   Email: goran.selander@ericsson.com





Navas, et al.              Expires May 4, 2017                 [Page 19]

Internet-Draft        LATe Synchronization Protocol         October 2016


   Ludwig Seitz
   SICS Swedish ICT
   Scheelevagen 17
   Lund  22370
   Sweden

   Email: ludwig@sics.se












































Navas, et al.              Expires May 4, 2017                 [Page 20]