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

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.

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 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:

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

Security Goals:

• Authentication: The time representation must be authenticated (data authentication).
• Freshness: The time representation must be fresh (See: [RFC4949]).

Actors:

• Time Client (TC): The entity that attempts to update its local time representation.
• Time Server (TS): The entity that provides its local time representation.

Assumptions:

• 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.
• The protocol messages are transported over unsecure communication channels. A datagram channel is assumed.
• 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.
• 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.

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

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 */
}

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)

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'
}

    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-----+
    |                  |                      |
    +                  +                      +

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 */
}

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'
}

    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.
    |                  |                      |
    +                  +                      +

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 */
}

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>
}