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


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

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

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:

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:

Security Goals:



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

Figure 1: Base Protocol

MSG1: From TC to TS. Contains:

MSG2: From TS to TC. Contains:

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

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.

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

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

Header: POST (Code=0.02)
Uri-Host: ""
Uri-Path: "time"
Content-Format: "application/late+cbor; late-type=tic"
 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.

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.

CBOR Map 'TOC Response' object definition
Parameter name CBOR Key Value Type description
time 3 (TBD) uint (TBD) A time representation information
nonce 4 (TBD) bstr A random nonce

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.

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"

  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:

  • 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.)
  • 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:

  • Active Time Synchronization:
    • Time Client contacts Time Server directly (min 2 messages)
    • Other Party initiates protocol (min 3 messages)
  • 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:

  • The ACE Authorization Server (AS) is the Time Server
  • The ACE Resource Server (RS) is the Time Client
  • 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)
  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.
  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"
 server     : 'coap://',
 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"
  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 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"
 server     : 'coaps://',
 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

  • Msg. 3. Token Request: additional parameter 'tic' will contain the 'TIC Information object' from message 2.
  • Msg. 4. Token Response: additional parameter 'toc' will contain the COSE Authenticated 'TOC Response'.
  • Msg. 5. Access Token POST: idem Token Response.

Message no. 5 on Figure 10.

Header: POST (Code=0.02)
Content-Format: "application/cwt+late; late-type=toc"
 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:

  • 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).
  • 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:
      • (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.
  • 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.
  • 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.
  • The PSK used for HMAC MUST be at least 256-bits long. (For AES-CBC-MAC or AES-CMAC 128-bit PSK will suffice)
  • 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)
  • 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
  • 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 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.
  • 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


10. References

10.1. Normative References

[I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S. and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE)", Internet-Draft draft-ietf-ace-oauth-authz-04, October 2016.
[I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", Internet-Draft draft-ietf-cose-msg-23, 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.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013.
[RFC7228] Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014.

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", Internet-Draft draft-ietf-ace-actors-04, 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)", Internet-Draft draft-ietf-ntp-cms-for-nts-message-06, February 2016.
[I-D.ietf-ntp-network-time-security] Sibold, D., Roettger, S. and K. Teichel, "Network Time Security", Internet-Draft draft-ietf-ntp-network-time-security-15, 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", Internet-Draft draft-ietf-oauth-pop-architecture-08, July 2016.
[RFC4086] Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.
[RFC5905] Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014.

Authors' Addresses

Renzo Navas Telecom Bretagne 2 rue de la Chataigneraie Cesson-Sevigne, 35510 France EMail:
Goeran Selander Ericsson AB Farogatan 6 Kista, SE-16480 Stockholm Sweden EMail:
Ludwig Seitz SICS Swedish ICT Scheelevagen 17 Lund, 22370 Sweden EMail: