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]