idnits 2.17.1 draft-navas-ace-secure-time-synchronization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-04 == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-23 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group R. Navas 3 Internet-Draft Telecom Bretagne 4 Intended status: Standards Track G. Selander 5 Expires: May 4, 2017 Ericsson AB 6 L. Seitz 7 SICS Swedish ICT 8 October 31, 2016 10 Lightweight Authenticated Time (LATe) Synchronization Protocol 11 draft-navas-ace-secure-time-synchronization-00 13 Abstract 15 This documents defines the Lightweight Authenticated Time (LATe) 16 Synchronization Protocol, a secure time synchronization protocol for 17 constrained environments. The messages are encoded using Concise 18 Binary Object Representation (CBOR) and basic security services are 19 provided by CBOR Object Signing and Encryption (COSE). A secure 20 source of time is a base assumption for many other services, 21 including security services. LATe Synchronization protocol enables 22 these time-dependent services to run in the context of a constrained 23 environment. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 4, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Protocol Goals, Actors and Assumptions . . . . . . . . . . . 4 63 3. Base Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Message Exchanges and Semantics . . . . . . . . . . . . . 5 65 3.2. Time Synchronization Calculation . . . . . . . . . . . . 6 66 4. Message Encodings . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. CBOR TIC and MSG1: Time Request . . . . . . . . . . . . . 7 68 4.2. CBOR TOC and MSG2: Time Representation Response . . . . . 9 69 5. Protocol Triggering . . . . . . . . . . . . . . . . . . . . . 10 70 6. Protocol on ACE Framework . . . . . . . . . . . . . . . . . . 11 71 6.1. Actors Mappings . . . . . . . . . . . . . . . . . . . . . 11 72 6.2. Possible Scenarios . . . . . . . . . . . . . . . . . . . 11 73 6.3. Solution For Scenario 1.1 . . . . . . . . . . . . . . . . 12 74 6.4. Solution For Scenario 1.2 . . . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 10.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Authentication and Authorization for Constrained Environments (ACE) 86 working group defined a framework for authentication and 87 authorization in Internet of Things (IoT) environments: the ACE 88 framework [I-D.ietf-ace-oauth-authz]. Many security services offered 89 rely on measuring time in constrained devices, for determining 90 validity of access tokens and freshness of requests. While clocks 91 are affordable in many settings, and energy consumption may be less 92 than intrinsic battery discharge, there is a need for synchronization 93 of time between the nodes. 95 We propose a secure time synchronization protocol in the context of 96 the ACE framework, where the time server is the Authorization Server. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. These 103 words may also appear in this document in lowercase, absent their 104 normative meanings. 106 Security terminology such as "nonce", "fresh", "random number 107 generator", is defined in [RFC4949]. 109 Terminology for constrained environments, such as "constrained 110 device", "constrained-node network", is defined in [RFC7228]. 112 A "Real-time clock" (RTC) is a computer clock that keeps track of the 113 current time, with low power consumption and using an alternate 114 source of power. 116 Readers are expected to be familiar with the terms and concepts 117 described in [I-D.ietf-ace-actors] and [I-D.ietf-ace-oauth-authz]. 119 1.2. Motivation 121 Authentication and Authorization for Constrained Environments (ACE) 122 framework is specified on [I-D.ietf-ace-oauth-authz]. The solution 123 relies on OAuth 2.0 framework and on OAuth 2.0 Proof-of-possession 124 tokens [I-D.ietf-oauth-pop-architecture]. The framework's security 125 services rely on token validation and expiration. In order to 126 validate a token (aside from a token introspection solution) the 127 Resource Server needs to have an internal time representation 128 synchronized with the Authorization Server. In order achieve that, a 129 secure time synchronization mechanism must be implemented. Solutions 130 such as (Simple) Network Time Protocol (S)NTP Version 4 [RFC5905], 131 widely used on the standard internet, falls short in the constrained 132 setting for several reasons. The fundamental reason is that it does 133 not achieve a secure and fresh source of time even running in the 134 authenticated mode, this shortcoming is explained on the "Security 135 Considerations" section of NTPv4: 137 "The lifetime of cryptographic values must be enforced, which 138 requires a reliable system clock. However, the sources that 139 synchronize the system clock must be trusted. This circular 140 interdependence of the timekeeping and authentication functions 141 requires special handling." 143 To break this circular dependence an hypothesis ("leap of faith") can 144 be made: the end-to-end communicating parties have valid pre-shared 145 cryptographic material. In the constrained environment setting, this 146 seems like a reasonable assumption e.g., nodes deployed with a pre- 147 shared key (PSK) with a trusted-third-party. If the source of time 148 then is trusted, then the fundamental security problem to solve is to 149 assure the freshness of a transaction. The freshness problem can be 150 solved with an appropriate use of 'nonces' within the protocol. 152 A comprehensive document about time protocol security requirements 153 can be found on "Security Requirements of Time Protocols in Packet 154 Switched Networks" [RFC7384]. 156 Current efforts to provide a solution to the secure time problem 157 includes the work-in-progress "Network Time Security (NTS)" 158 [I-D.ietf-ntp-network-time-security] which provides mechanisms to 159 secure an existing time protocol. NTS is not constrained-environment 160 friendly. In order to establish a basic time synchronization 161 exchange, six messages should be exchanged (Association Exchange, 162 Cookie Exchange, and finally unicast time synchronization). 163 Furthermore current time protocols such as (S)NTPv4 are not designed 164 for constrained environments either. The combination of both such as 165 in "NTS for NTPv4 using Cryptographic Message Syntax (CMS)" 166 [I-D.ietf-ntp-cms-for-nts-message] is certainly not suited for the 167 ACE Scenario. 169 This documents defines the "Lightweight Authenticated Time (LATe) 170 Synchronization Protocol", which provides a secure time 171 synchronization protocol suited for constrained environments. Using 172 this protocol on top of the ACE framework is one of the design goals. 174 2. Protocol Goals, Actors and Assumptions 176 Functional Goal: 178 o The protocol enables a constrained node to obtain a local time 179 representation from a trusted entity, with an associated +/- 180 uncertainty. 182 Security Goals: 184 o Authentication: The time representation must be authenticated 185 (data authentication). 187 o Freshness: The time representation must be fresh (See: [RFC4949]). 189 Actors: 191 o Time Client (TC): The entity that attempts to update its local 192 time representation. 194 o Time Server (TS): The entity that provides its local time 195 representation. 197 Assumptions: 199 o TC and TS MUST have valid pre-shared cryptographic material. For 200 symmetric cryptography the key MUST be shared only by TC and TS, 201 no third party. For the rest of this document symmetric key 202 cryptography is assumed. 204 o The protocol messages are transported over unsecure communication 205 channels. A datagram channel is assumed. 207 o TC MUST have self-powered relative time-awareness capabilities, 208 i.e., a Real-Time Clock. If not self-powered, a reboot of the 209 node can be a security breach. 211 o The time-sensitive application that uses this protocol MUST 212 tolerate a time uncertainty of at least half the round-trip time 213 (RTT) measured from TC to TS (e.g., if RTT is 6 seconds, then time 214 uncertainty tolerated must be greater than +/- 3 seconds). 216 3. Base Protocol 218 This section describes the base time synchronization protocol for 219 constrained environments. This protocol is designed to be embedded 220 on the ACE framework [I-D.ietf-ace-oauth-authz], this is detailed on 221 Section 6. 223 This base-protocol-first approach permits an easier understanding and 224 scrutiny of the protocol and the goals it claims to achieve from a 225 functional and security point of view. A flaw on the base protocol 226 implies a flaw on the embedded-on-ACE protocol. 228 3.1. Message Exchanges and Semantics 230 The protocol consists of two messages that are represented on 231 Figure 1. 233 Time Server Time Client 234 + + 235 | | 236 | | 237 | Nonce_TC,Key-ID | 238 <------------------------------------+ (MSG1) 239 | | 240 | | 241 | | 242 | Nonce_TC,TS_Time | 243 +------------------------------------> (MSG2) 244 | Authentication(Nonce_TC,TS_Time) | 245 | | 246 | | 248 Figure 1: Base Protocol 250 MSG1: From TC to TS. Contains: 252 o A nonce generated by TC (Nonce_TC). The nonce MUST be at least 253 64-bits and random (A pseudo-random number generator can be used 254 if the seed value has sufficient entropy). 256 o A Key-Id (opaque) to indicate to TS which cryptographic Key to use 257 to authenticate the response. 259 MSG2: From TS to TC. Contains: 261 o The same nonce received on MSG1 (Nonce_TC) 263 o The local time representation of TS (TS_Time) 265 o Authentication information (e.g., a MAC) for the message 266 (Nonce_TC,TS_Time), i.e., an authentication "tag". 268 3.2. Time Synchronization Calculation 270 The Time Client will have to run the following Algorithm to achieve 271 authenticated time synchronization: 273 1. TC Internally timestamps when it sends MSG1 (T1). 275 2. TC Authenticates MSG2 (Contains: Nonce_TC and Time_TS). 277 3. TC Verifies nonce on MSG2 matches Nonce_TC sent on MSG1. 279 4. TC Calculates RTT = (TC_Current - T1), and verifies that RTT is 280 within the acceptable range. 282 5. TC set his internal clock Time_TC = Time_TS + (RTT/2). 284 NOTE: TC does not send any message to TS after receiving MSG2, 285 neither in case of success or failure. 287 4. Message Encodings 289 The messages are encoded in CBOR [RFC7049]. CBOR Object Signing and 290 Encryption (COSE) [I-D.ietf-cose-msg] is used to cryptographically 291 protect the message. This protocol will define and use two new CBOR 292 objects: 'TIC Information' and 'TOC Response'. 294 The ACE framework uses CoAP [RFC7252] as application protocol and 295 this protocol also assumes CoAP to transport the CBOR messages. CoAP 296 options "Uri-Path" and "Content-Format" are used to identify a run of 297 this protocol. The protocol, however, is designed to be as 298 independent as possible on the underlying layers to facilitate its 299 use on top of any other datagram oriented mechanism with application 300 multiplexing or to be nested inside other CBOR/COSE objects. 302 4.1. CBOR TIC and MSG1: Time Request 304 The Time Request is sent from the Time Client to the Time Server. 305 The Time Request message will be a CoAP POST to the "/time" resource 306 of TS (Content-Type: "application/late+cbor; late-type=tic"). The 307 CoAP payload will contain a new CBOR Map 'TIC Information' object as 308 defined on Table 1. 310 +------------+-------+-------+-----------+--------------------------+ 311 | Parameter | CBOR | Value | registry | description | 312 | name | Key | Type | | | 313 +------------+-------+-------+-----------+--------------------------+ 314 | nonce | 4 | bstr | | A random nonce | 315 | | (TBD) | | | | 316 | | | | | | 317 | kid | 5 | bstr | | Key-ID is an opaque | 318 | | (TBD) | | | value and identifies the | 319 | | | | | cryptographic key to be | 320 | | | | | used in the response | 321 | | | | | | 322 | alg | 6 | int | COSE | Identifies the | 323 | (optional) | (TBD) | | Algorithm | cryptographic algorithm | 324 | | | | Values | to be used in the | 325 | | | | | response | 326 | | | | | | 327 | server | 7 | tstr | | Identifies the intended | 328 | (optional) | (TBD) | | | Server for time | 329 | | | | | synchronization | 330 | | | | | (Absolute-URI) | 331 +------------+-------+-------+-----------+--------------------------+ 333 Table 1: CBOR Map 'TIC Information' object definition 335 A Time Request (MSG 1) message example is shown in Figure 2 using 336 CBOR diagnostic notation. 338 Header: POST (Code=0.02) 339 Uri-Host: "server.org" 340 Uri-Path: "time" 341 Content-Format: "application/late+cbor; late-type=tic" 342 Payload: 343 { 344 nonce : h'73616e206c6f7265', 345 kid : h'0001', 346 alg : 4 /* HMAC w/ SHA-256 truncated to 64 bits */ 347 } 349 Figure 2: MSG1 example in CBOR diagnostic notation 351 Figure 3 illustrates the binary encoding (17 Bytes) of the CoAP 352 payload (i.e., CBOR TIC) shown in Figure 2. 354 a3 # map(3) 355 04 # unsigned(4) (=nonce) 356 50 # bytes(8) 357 73616e206c6f7265 # 358 05 # unsigned(5) (=kid) 359 42 # bytes(2) 360 0001 # 361 06 # unsigned(6) (=alg) 362 04 # unsigned(4) 364 Figure 3: MSG1 Payload: 'TIC Information' CBOR object (17 Bytes) 366 4.2. CBOR TOC and MSG2: Time Representation Response 368 The Time Representation response message is sent from the Time Server 369 to the Time Client. The CoAP Content-Type will be set to 370 "application/late+cose;cose-type=cose-mac; late-type=toc". The 371 message will contain the Nonce received on the Time Request ('nonce') 372 and the Time Representation of the Time Server ('time') (TBD how to 373 represent time). The 'nonce' and 'time' information will be encoded 374 using a CBOR Map object 'TOC Response' as defined on Table 2. 376 +---------------+---------+-----------+-----------------------------+ 377 | Parameter | CBOR | Value | description | 378 | name | Key | Type | | 379 +---------------+---------+-----------+-----------------------------+ 380 | time | 3 (TBD) | uint | A time representation | 381 | | | (TBD) | information | 382 | | | | | 383 | nonce | 4 (TBD) | bstr | A random nonce | 384 +---------------+---------+-----------+-----------------------------+ 386 Table 2: CBOR Map 'TOC Response' object definition 388 The 'TOC Response' object MUST be authenticated using the key ('kid') 389 and algorithm ('alg', if present) specified on the Time Request. 390 This authenticated message will be encoded using a COSE_Mac0 391 structure. 393 The 'TOC Response' MUST be placed on the 'payload' part of the 394 COSE_Mac0 stucture. If 'alg' was present on the Time Request it MUST 395 be placed on the 'protected' header of the Response, if 'alg' was not 396 present on the Time Request it MUST NOT be present on the Response. 397 ('kid' TBD) The 'kid' MUST be either: placed on the 'protected' 398 header, or supplied as 'external_aad' in the COSE MAC_structure to 399 compute the mac. 401 An example of a Time Representation message is shown on Figure 4 402 using non-normative CBOR diagnostic notation to make it easier to 403 understand. 405 Header: Changed (Code=2.04) 406 Content-Type: "application/late+cose; 407 cose-type=cose-mac; late-type=toc" 408 Payload: 410 { 411 protected : { 412 kid: h'0001', 413 alg: 4 /* HMAC w/ SHA-256 truncated to 64 bits */ 414 }, 415 payload : { 416 time : 1477307841, 417 nonce : h'73616e206c6f7265' 418 }, 419 tag : h'36f5afaf0bab5d43' 420 } 422 Figure 4: MSG2 example COSE-MACed 'TOC Response' in CBOR diagnostic 423 notation 425 An implementation of this specification MUST implement the MAC 426 algorithm "HMAC w/ SHA-256 truncated to 64 bits" as specified on 427 [I-D.ietf-cose-msg]. The PSK used for HMAC MUST be at least 256-bits 428 long. Rationale: a CoAP implementation with DTLS on PSK mode 429 requires the cipher suite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655], which 430 already includes HMAC with SHA-256. 432 5. Protocol Triggering 434 An important property of the protocol is when and how to trigger the 435 execution of it. While conditions for the trigger itself will be 436 application-dependent, this section goal is to give useful general 437 thoughts on the matter. 439 There is a difference between the 'trigger' itself, that indicates 440 that a time synchronization protocol must be run, and the actual 441 execution of the protocol (e.g., it can be delayed). 443 There can be two types of triggers: 445 o Internal Trigger: The Time Clients determines it needs to 446 synchronize its time. (Real-Time Clocks are needed to avoid 447 possible attacks. e.g., reset node and force time sync.) 449 o External Trigger: Other party determines that the Time Client 450 needs to synchronize its time. (request must be authenticated and 451 reply-protected or fresh) 453 As for the protocol execution itself the following categories are 454 defined: 456 o Active Time Synchronization: 458 * Time Client contacts Time Server directly (min 2 messages) 460 * Other Party initiates protocol (min 3 messages) 462 o Opportunistic/Passive Time Synchronization 464 * The protocol is initiated when the Time Client receives any 465 message from a third-party. The third-party (if supports the 466 protocol) will be used as a relay from the Time Client to the 467 Time Server. 469 6. Protocol on ACE Framework 471 6.1. Actors Mappings 473 The Actors on this protocol will map on the ACE Framework as follows: 475 o The ACE Authorization Server (AS) is the Time Server 477 o The ACE Resource Server (RS) is the Time Client 479 o The ACE Client (C) will relay messages. 481 6.2. Possible Scenarios 483 We characterize the scenarios by the first messages on the 484 interaction: 486 1. First Message C -> RS: Resource Request 488 1. Response: Time Synchronization only needed 490 2. Response: Time Synchronization + Access Token needed 492 2. First Message C -> AS: ACE Basic Protocol Flow 494 3. First Message RS -> AS: Direct Communication (RS Can do 495 Introspection) 497 4. TBD 499 6.3. Solution For Scenario 1.1 501 The First Message is from C to RS. The Client sends a Resource 502 Request to the RS (Time Client). RS has internally triggered the 503 need for time synchronization so opportunistically will initiate the 504 LATe Synchronization Protocol by sending a TIC Information object. 505 The message flow for this scenario is summarized on Figure 5. 507 AS C RS 508 (Time Server) | (Time Client) 509 | | | 510 | +------ Res. Req.----->+ 511 | | | 512 | | | 513 | +<-4.01 Unauthorized---+ 514 | | (TIC Info) | 515 +<---LATe MSG1-----+ | 516 | | | 517 | | | 518 +----LATe MSG2---->+ | 519 | | | 520 | +-------POST /time---->+ /time 521 | | (AUTH TOC Response) | 522 | | | 523 | +<----2.04 Changed-----+ 524 | | | 525 + + + 527 Figure 5: LATe on ACE Scenario 1 529 A detailed description of the message flows and contents goes as 530 follows: 532 1. C to RS: Resource Request. 534 2. RS to C: RS responds with a CoAP response code 4.01 535 (Unauthorized) containing a CBOR TIC Information object (Content- 536 Type: "application/late+cbor; late-type=tic"), the TIC 537 information MUST contain the time server (AS) Absolute-URI. 539 3. C to AS: C will act as a proxy and forward the "LATe MSG1" from 540 the base protocol to AS using the TIC Information from RS. 542 4. AS to C: As will reply a "LATe MSG2" as specified on the base 543 protocol. 545 5. C will forward the payload from "LATe MSG2" without any 546 modification, which consists of a COSE Authenticated TOC Response 547 object, and send it as the payload of a CoAP POST to the "/time" 548 resource on RS (Content-Type: "application/late+cose;cose- 549 type=cose-mac; late-type=toc"). 551 6. RS to C: Responds with the appropriate response code (e.g., "2.04 552 Changed")(TBD do not reply) 554 An example of messages 2 and 5 are shown on Figure 6 and Figure 7 555 respectively. 557 Header: 4.01 Unauthorized 558 Content-Type: "application/late+cbor; late-type=tic" 559 Payload: 560 { 561 server : 'coap://server.org/time', 562 nonce : h'73616e206c6f7265', 563 kid : h'0001', 564 alg : 4 /* HMAC w/ SHA-256 truncated to 64 bits */ 565 } 567 Figure 6: Unauthorized Response with a TIC Information object 569 Header: POST (Code=0.02) 570 Uri-Path: "time" 571 Content-Type: "application/late+cose; 572 cose-type=cose-mac; late-type=toc" 573 Payload: 574 { 575 protected : { 576 kid: h'0001', 577 alg: 4 /* HMAC w/ SHA-256 truncated to 64 bits */ 578 }, 579 payload : { 580 time : 1477307841, 581 nonce : h'73616e206c6f7265' 582 }, 583 tag : h'36f5afaf0bab5d43' 584 } 586 Figure 7: CoaP POST /time of an Authenticated TOC Response object 588 6.4. Solution For Scenario 1.2 590 The First Message is from C to RS. The Client sends a Resource 591 Request to the RS (Time Client). C does not yet have a secure 592 association with RS. ACE protocol will be triggered. RS has 593 internally triggered the need for time synchronization so 594 opportunistically will initiate the LATe Synchronization Protocol by 595 sending a TIC Information object. The message flow for this scenario 596 is summarized on Figure 8. 598 AS C RS 599 (Time Server) | (Time Client) 600 | | | 601 | +--Unauthz.Res. Req.-->+ 1. 602 | | | 603 | | | 604 | +<-4.01 Unauthorized---+ 2. 605 | | (ACE Info + TIC) | 606 3. +<---Token Request-+ | 607 | + TIC | | 608 | | | 609 4. +--Token Response->+ | 610 | + AUTH TOC | | 611 | +---POST /authz-inf--->+ 5. 612 | | (Token + AUTH TOC) | 613 | | | 614 | +<----2.04 Changed-----+ 6. 615 | | | 616 + + + 618 Figure 8: LATe on ACE Scenario 1.2 620 Message no. 2 is depicted on Figure 9. 622 Header: 4.01 Unauthorized 623 Content-Type: "application/ace+late+cbor; late-type=tic" 624 Payload: 625 { 626 server : 'coaps://as.org/token', 627 nonce : h'73616e206c6f7265', 628 kid : h'0001', 629 alg : 4 /* HMAC w/ SHA-256 truncated to 64 bits */ 630 } 632 Figure 9: Unauthorized Response with a TIC Information object + 633 Initiation of the ACE Protocol 635 o Msg. 3. Token Request: additional parameter 'tic' will contain 636 the 'TIC Information object' from message 2. 638 o Msg. 4. Token Response: additional parameter 'toc' will contain 639 the COSE Authenticated 'TOC Response'. 641 o Msg. 5. Access Token POST: idem Token Response. 643 Message no. 5 on Figure 10. 645 Header: POST (Code=0.02) 646 Uri-Path:"authz-info" 647 Content-Format: "application/cwt+late; late-type=toc" 648 Payload: 649 { 650 toc : 651 cwt : 652 } 654 Figure 10: Possible message 5: CWT + TOC 656 7. Security Considerations 658 Security goals and concerns have guided the design of this protocol. 659 The whole document has security recommendations and notes. See 660 Section 2 for the explicit security goals. We summarize most of 661 security-related information on this section, with the addition of 662 some more considerations: 664 o This protocol security goals are information authentication 665 (source-destination authentication) and freshness, as stated on 666 Section 2. 668 * NOTE: An asymmetric-cryptography variant of this protocol only 669 providing TS source authentication for MSG2 will be a weaker 670 version subject to a much higher probability of successful 671 attack; in that case MSG2 MUST be also confidentiality 672 protected for TC; another solution is authenticate the ID of 673 the intended recipient (TC-id, or use kid). 675 o Nonce generation: The nonce MUST be at least a 64-bit uniformly- 676 distributed random number. A pseudo-random number generator 677 (PRNG) MAY be used if the seed value has sufficient entropy. For 678 detailed guidelines on randomness see [RFC4086]. About the length 679 of the nonce: 64-bit-length will have a probability of collision 680 around 2^-32 for 2^16 uses of the protocol, and 50% for 2^32 uses; 681 depending on the application this may suffice. Longer nonces MAY 682 be used if 64-bit-lenght does not provide enough security in the 683 estimated lifetime of the node-key (or estimated attacker 684 capabilities). See "birthday attack" [RFC4949]. 686 * Discuss other lightweight alternatives for randomness: 688 + (1) An incremental counter stored on non-volatile memory 689 used as an input of a PRNG may be used (use of non-volatile 690 memory comes with challenges itself e.g., no. of writes, 691 tampering). 693 + (2) If MSG1 and MSG2 are authenticated and encrypted, a 694 plaintext counter stored on non-volatile memory may be 695 sufficient. 697 o About Real-Time Clocks (RTC): The Time Client MUST have a RTC. 698 The protocol's possible attacks where not studied in case of TC 699 not having a RTC Clock. Also the Time Server MUST have a RTC, as 700 it is the secure source of time (out of scope TS attacks). 701 Surprisingly, non-constrained nodes (Class 2 [RFC7228]) such as 702 Raspberry Pi or Arduino-Mega, which are often used as powerful 703 nodes on constrained environments, do not have a RTC, making them 704 constrained in the sense of time-awareness. NOTE: An update of 705 the RFC7228 (RFC7228-bis) will clarify the constraints in terms of 706 time. 708 o An implementation of this specification MUST implement the MAC 709 algorithm "HMAC w/ SHA-256 truncated to 64 bits" as specified on 710 [I-D.ietf-cose-msg]. The protocol provides crypto-agility to use 711 another algorithm in case the aforementioned gets compromised in 712 the future. 714 o The PSK used for HMAC MUST be at least 256-bits long. (For AES- 715 CBC-MAC or AES-CMAC 128-bit PSK will suffice) 717 o The use of a dedicated PSK only for this time synchronization 718 protocol is RECOMMENDED. Use of the key for other purposes (e.g.: 719 application data encryption) will increase the probability of the 720 key being compromised or this protocol being broken. The Time 721 synchronization PSK, and other keys used by the node, can be 722 securely derived from a Master-Key (this is out of scope) 724 o A stronger version of this protocol can be achieved by using 725 authenticated and encrypted MSG1 and MSG2. However this solution 726 will require more resources at the Time Client (more encryption/ 727 decryption operations, and probably more bits-over-the-air to 728 transmit -i.e., more energy-). There is always a trade-off 729 between resource-friendly and stronger security. The current 730 version of the protocol provides a lightweight solution yet 731 providing the security goals from Section 2 733 o Time Server DoS Attack. As MSG1 from the base protocol does not 734 impose any security service, the Time Server (or Authorization 735 Server) is highly exposed to DoS Attacks. To mitigate this, and 736 at the same time decrease the probability of a successful attack 737 to the protocol, we can Authenticate the MSG1 from the Time 738 Client. This mitigation is limited though, as an attacker with a 739 valid MSG1 can replay it. A Replay-protection mechanism should be 740 used such as using authenticated IVs. This replay-protection 741 mitigation is out of scope, but it can rely on COSE messages 742 secure properties. 744 o Time Client DoS Attack. TC is exposed to DoS attacks. To 745 mitigate to the greatest extent possible rejection of MSG2 should 746 be done on the least resource-consuming way. No response might be 747 given in case of success of failure of the protocol. External 748 triggering of the protocol must be also carefully secure 749 (authenticated plus replay protection or fresh). 751 8. Privacy Considerations 753 The protocol sends the Time Server's time representation on 754 plaintext. It is only authenticated. This might be an undesired 755 privacy breach. To completely mitigate this concern MSG2 of the base 756 protocol must be authenticated and encrypted (AE). 758 MSG1 of the base protocol needs, at minimum, to identify the 759 cryptographic key that will have to be used on the response. 760 Initially the TC's Identity (e.g, URI) was pondered as a solution (in 761 fact, TC's ID may be known to the party interacting with it). But 762 unique and static identification information is on the opposite 763 direction of privacy goals. Hence a trade-off has to be made, and we 764 chose the minimum identification required to run the protocol, that 765 is to send an opaque key-id. Key-id is static in this protocol, 766 which can be used for fingerprinting, but a method to change it 767 dynamically can exist (out of scope). Any other opaque, or dynamic, 768 identifier may be used, still guaranteeing an appropriate level of 769 privacy. Entity-ID, Resource-ID, Security Association ID, IDs in 770 general and Privacy is a topic yet to be properly studied on the ACE 771 context. 773 9. IANA Considerations 775 TBD 777 10. References 779 10.1. Normative References 781 [I-D.ietf-ace-oauth-authz] 782 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 783 H. Tschofenig, "Authentication and Authorization for 784 Constrained Environments (ACE)", draft-ietf-ace-oauth- 785 authz-04 (work in progress), October 2016. 787 [I-D.ietf-cose-msg] 788 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 789 draft-ietf-cose-msg-23 (work in progress), October 2016. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 797 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 798 October 2013, . 800 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 801 Constrained-Node Networks", RFC 7228, 802 DOI 10.17487/RFC7228, May 2014, 803 . 805 10.2. Informative References 807 [I-D.ietf-ace-actors] 808 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 809 architecture for authorization in constrained 810 environments", draft-ietf-ace-actors-04 (work in 811 progress), September 2016. 813 [I-D.ietf-ntp-cms-for-nts-message] 814 Sibold, D., Teichel, K., Roettger, S., and R. Housley, 815 "Protecting Network Time Security Messages with the 816 Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- 817 for-nts-message-06 (work in progress), February 2016. 819 [I-D.ietf-ntp-network-time-security] 820 Sibold, D., Roettger, S., and K. Teichel, "Network Time 821 Security", draft-ietf-ntp-network-time-security-15 (work 822 in progress), September 2016. 824 [I-D.ietf-oauth-pop-architecture] 825 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 826 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 827 Architecture", draft-ietf-oauth-pop-architecture-08 (work 828 in progress), July 2016. 830 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 831 "Randomness Requirements for Security", BCP 106, RFC 4086, 832 DOI 10.17487/RFC4086, June 2005, 833 . 835 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 836 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 837 . 839 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 840 "Network Time Protocol Version 4: Protocol and Algorithms 841 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 842 . 844 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 845 Transport Layer Security (TLS)", RFC 6655, 846 DOI 10.17487/RFC6655, July 2012, 847 . 849 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 850 Application Protocol (CoAP)", RFC 7252, 851 DOI 10.17487/RFC7252, June 2014, 852 . 854 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 855 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 856 October 2014, . 858 Authors' Addresses 860 Renzo Navas 861 Telecom Bretagne 862 2 rue de la Chataigneraie 863 Cesson-Sevigne 35510 864 France 866 Email: renzo.navas@telecom-bretagne.eu 868 Goeran Selander 869 Ericsson AB 870 Farogatan 6 871 Kista SE-16480 Stockholm 872 Sweden 874 Email: goran.selander@ericsson.com 875 Ludwig Seitz 876 SICS Swedish ICT 877 Scheelevagen 17 878 Lund 22370 879 Sweden 881 Email: ludwig@sics.se