idnits 2.17.1 draft-shaw-rats-rear-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 June 2020) is 1404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-04 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-02 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-05 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS A. Shaw 3 Internet-Draft H. Tschofenig 4 Intended status: Informational S. Trofimov 5 Expires: 14 December 2020 S. Frost 6 T. Fossati 7 arm 8 12 June 2020 10 Restful Attested Resources 11 draft-shaw-rats-rear-00 13 Abstract 15 This memo describes a REST interface based on the RATS architecture 16 that can be used to retrieve attested system state, for example the 17 reading of a security critical sensor. The objective is to present a 18 common vocabulary of data formats and basic protocol transactions 19 that can be pieced together into a cohesive interface that is capable 20 of serving different attestation workflows. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 14 December 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Document Organisation . . . . . . . . . . . . . . . . . . 4 58 1.3. Conventions used in this document . . . . . . . . . . . . 4 59 2. Abstract Mechanism . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Attester Interface . . . . . . . . . . . . . . . . . . . 4 61 2.1.1. Resource Validation . . . . . . . . . . . . . . . . . 5 62 2.2. Verifier Interface . . . . . . . . . . . . . . . . . . . 5 63 2.2.1. Attestation Result Validation . . . . . . . . . . . . 6 64 2.3. Example Compositions . . . . . . . . . . . . . . . . . . 6 65 2.3.1. Background Check with Nonce-based Freshness . . . . . 6 66 2.3.2. Background Check with Timestamp-based Freshness . . . 7 67 2.3.3. Passport with Timestamp-based Freshness . . . . . . . 7 68 2.3.4. Timestamp-based Uni-directional . . . . . . . . . . . 8 69 3. REST Instantiation . . . . . . . . . . . . . . . . . . . . . 9 70 3.1. Basic Data Formats . . . . . . . . . . . . . . . . . . . 9 71 3.1.1. Resource . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.3. Timestamp . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1.4. Evidence . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1.5. Attestation Result . . . . . . . . . . . . . . . . . 10 76 3.2. Request and Response Payloads . . . . . . . . . . . . . . 10 77 3.2.1. Requesting an Attested Resource . . . . . . . . . . . 10 78 3.2.2. Attested Resource . . . . . . . . . . . . . . . . . . 10 79 3.2.3. Request for Attestation Result . . . . . . . . . . . 11 80 3.2.4. Verifier Response . . . . . . . . . . . . . . . . . . 11 81 3.3. Interaction Model . . . . . . . . . . . . . . . . . . . . 12 82 3.3.1. Channel Security Considerations . . . . . . . . . . . 12 83 3.3.2. URLs . . . . . . . . . . . . . . . . . . . . . . . . 12 84 3.3.3. Methods . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.3.4. Multicast Support . . . . . . . . . . . . . . . . . . 13 86 3.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 13 87 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 4.1. Resource Directory . . . . . . . . . . . . . . . . . . . 17 89 4.1.1. Attested Resource Registration . . . . . . . . . . . 17 90 4.1.2. Verifier Resource Registration . . . . . . . . . . . 19 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 7.1. Model Architecture for the Origin . . . . . . . . . . . . 20 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 Normative References . . . . . . . . . . . . . . . . . . . . . 20 98 Informative References . . . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 This memo describes a REST [Fielding] interface based on the RATS 104 architecture [I-D.ietf-rats-architecture] that can be used to 105 retrieve attested system state, for example the reading of a security 106 critical sensor. 108 We present a simple vocabulary of data formats and basic protocol 109 transactions that can be pieced together into a cohesive interface 110 capable of serving different attestation workflows. At a minimum, we 111 want to cater for the "background check" and "passport" topological 112 models, and for freshness of attestation based on nonces as well as 113 timestamps. 115 The obvious advantage of sharing a uniform interface across different 116 actors is it creates an ecosystem in which variability is minimised 117 and so is the need to add complex and often fragile logics into the 118 deployed components, e.g., data format and protocol translation. 119 Besides, using the familiar REST toolbox provides additional benefits 120 in terms of developer friendliness as well as code base and 121 infrastructure reuse (e.g., web caching). 123 1.1. Use Cases 125 The primary use case is that of a device that needs to provide 126 application state to third parties with strong authenticity. 128 This is a common situation in critical infrastructure systems where 129 an actuator device needs some assurance that the sensing equipment is 130 in pristine state before acting on its signals. Here, the sensor 131 would expose its safety critical samples via an attested resource 132 whose authenticity can be verified by the actuator. 134 Another potential application is a fleet controller that needs to 135 know the current state of its dependent devices to inform its next 136 actions (e.g., scheduling a firmware update campaign). Here, the 137 dependent devices uniformly expose the same resource (e.g., the list 138 of currently installed software components) to the controller, which 139 can decide, based on the information provided, which devices need a 140 certain security patch. 142 Many more use cases exist. 144 1.2. Document Organisation 146 The remainder of this document describes: 148 * An abstract protocol that allows a device to expose arbitrary 149 attested system state, which can be consumed by third parties 150 (Section 2); 151 * An instantiation of said abstract protocol as a set of uniform 152 data formats and interaction primitives based on the REST paradigm 153 for both HTTP [RFC7230] and CoAP [RFC7252] (Section 3); 154 * A way to advertise and discover said capability (Section 4). 156 1.3. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 2. Abstract Mechanism 166 The protocol principals are the three RATS actors: the attester (A), 167 the relying party (RP) and the verifier (V). 169 It is assumed that A either directly owns a resource, r, or has a 170 direct trust relationship with the resource owner. 172 In the following, "n" and "t" are freshness indicators: "n" is an 173 initiator provided nonce, "t" is a timestamp sourced by the 174 responder. When using timestamp based freshness, producers' and 175 consumers' clocks MUST be synchronised. 177 2.1. Attester Interface 179 The interface to the Attester is illustrated in Figure 1. 181 X is any entity interacting with the Attester, typically a Relying 182 Party, which wants to retrieve an attested resource. 184 A function "E(n_X, r, t_A)" is used by A to compute an evidence 185 report binding the device status to the resource ("r") together with 186 the freshness indicators "n_X" and "t_A". Typically, only one of 187 "n_X" or "t_A" will be present. 189 "E()" outputs an EAT token [I-D.ietf-rats-eat], "E", carrying a 190 "nonce" claim that is used as described in the following. 192 The binding between "n_X", "t_A" and "r" is obtained by hashing their 193 concatenation, "H(n_X || r || t_A)", and storing the result in the 194 "nonce" claim which is then cryptographically signed by the Attester 195 as part of the produced evidence, "E". The presence of any freshness 196 indicator (i.e., "n_X" or "t_A") is optional. For the purpose of 197 computing "E", a nil freshness indicator is replaced by the zero- 198 length string, "". If "t_A != nil", then its value needs to be sent 199 back to the requester as an additional explicit protocol entity. 201 Optionally, an attestation result "R" computed on evidence "E" MAY be 202 returned by an Attester that acts as a forwarder for a Verifier. 204 X A 205 | n_X=nil | 206 o-------------------------------------->| 207 | r, t_A=nil, E(n_X, r, t_A), R(E)=nil | 208 |<--------------------------------------o 209 | | 211 Figure 1: Attester Interface 213 2.1.1. Resource Validation 215 Given an Appraisal Policy for Evidence "APE" and an Appraisal Policy 216 for Attestation Result "APR", X accepts "r" if and only if: 218 * "E | APE => true" 219 * "E.nonce == H(n_X || r || t_A)" 221 If "R(E)!=nil", two further conditions MUST hold: 223 * "R(E) | APR => true" 224 * "R.nonce == H("" || E || "")" 226 Note that not all the appraisal operations are computed directly by 227 X. For example, "E | APE" is typically delegated to a trusted 228 Verifier. 230 2.2. Verifier Interface 232 The interface to the Verifier is illustrated in Figure 2. 234 Y is any entity interacting with the Verifier, e.g., a Relying Party 235 or an Attester, which supplies an evidence and receives an 236 attestation result. 238 The function "R(n_Y, E, t_V)" is used by V to compute the attestation 239 result over "E" using an implicit Appraisal Policy for Evidence 240 "APE". The result is cryptographically signed by V and bound to any 241 available freshness indicator. 243 "R()" outputs an EAT token [I-D.ietf-rats-eat], "R", carrying at a 244 minimum: 246 * a "result" claim carrying a boolean value that reflects the 247 validity of the submitted evidence given the Appraisal Policy for 248 Evidence used by the Verifier; 249 * a "nonce" claim that is used as described in the following. 251 The token MAY contain further information associated with the 252 evidence validation process. 254 The binding between "n_Y", "t_V" and "E" is obtained by hashing their 255 concatenation, "H(n_Y || E || t_V)", and storing the result in the 256 "nonce" claim which is then cryptographically signed by the Verifier 257 as part of the produced attestation result, "R". The presence of any 258 freshness indicator (i.e., "n_Y" or "t_V") is optional. For the 259 purpose of computing "R", a nil freshness indicator is replaced by 260 the zero-length string, "". 262 Y V 263 | n_Y=nil, E | 264 o----------------------------->| 265 | t_V=nil, R(n_Y, E, t_V) | 266 |<-----------------------------o 267 | | 269 Figure 2: Verifier Interface 271 2.2.1. Attestation Result Validation 273 Given an Appraisal Policy for Attestation Result "APR", Y accepts "R" 274 if and only if: 276 * "R(E) | APR => true" 277 * "R.nonce == H(n_Y || E || t_V)" 279 2.3. Example Compositions 281 2.3.1. Background Check with Nonce-based Freshness 282 A RP V 283 | n_X | | 284 |<-----------------------------o | 285 | r, E(n_X, r, nil) | | 286 o----------------------------->| | 287 | | E | 288 | o----------------------------->| 289 | | R(nil, E, nil) | 290 | |<-----------------------------o 291 | | | 293 Figure 3: Background Check with Nonce-based Freshness 295 RP accepts "r" if and only if: 297 * "E | APE => true" 298 * "E.nonce == H(n_X || r || "")" 299 * "R | APR => true", or equivalently "R.result == true" 300 * "R.nonce == H("" || E || "")" 302 2.3.2. Background Check with Timestamp-based Freshness 304 A RP V 305 | nil | | 306 |<-----------------------------o | 307 | r, t_A, E(nil, r, t_A) | | 308 o----------------------------->| | 309 | | E | 310 | o----------------------------->| 311 | | R(nil, E, nil) | 312 | |<-----------------------------o 313 | | | 315 Figure 4: Background Check with Timestamp-based Freshness 317 RP accepts r if and only if: 319 * "R | APR => true", or equivalently "R.result == true" 320 * "R.nonce == H("" || E || "")" 321 * "E | APE => true" 322 * "E.nonce == H("" || r || t_A)" 324 2.3.3. Passport with Timestamp-based Freshness 326 The idea is that whenever the state of r changes, the Attester will 327 "self-issue" an evidence for the changed resource using a locally 328 sourced timestamp ("t_A") as the freshness indicator. 330 A 331 .--o 332 | | 333 '->o--. 334 | | r, t_A, E(nil, r, t_A) 335 |<-' 336 | V 337 | E | 338 o------------------------------------------------------------>| 339 | R(nil, E, nil) | 340 |<------------------------------------------------------------o 341 | | 342 | RP 343 | nil | 344 |<-----------------------------o 345 | r, t_A, E(nil, r, t_A), | 346 | R(nil, E, nil) | 347 o----------------------------->| 349 Figure 5: Passport with Timestamp-based Freshness 351 RP accepts r if and only if: 353 * "R | APR => true" 354 * "R.nonce == H("" || E || "")" 355 * "E.nonce == H("" || r || t_A)" 357 2.3.4. Timestamp-based Uni-directional 359 If the transport allows it, timestamp-based uni-directional 360 attestation protocols, e.g., TUDA [I-D.birkholz-rats-tuda], can also 361 be constructed from the presented primitives. For example, using 362 CoAP Observe [RFC7641] the interaction pattern in Figure 6, with an 363 initial trigger and subsequent automatic updates on resource status 364 change, can be naturally implemented. 366 A RP 367 | nil | 368 |<-----------------------------o 369 | r_1, t_A, E(nil, r_1, t_A) | 370 o----------------------------->| 371 | | 372 | [...] | 373 | | 374 | r_i, t_A, E(nil, r_i, t_A) | 375 o----------------------------->| 376 | | 377 | [...] | 378 | | 379 | r_n, t_A, E(nil, r_n, t_A) | 380 o----------------------------->| 382 Figure 6: Timestamp-based Uni-directional 384 3. REST Instantiation 386 Four new MIME types are defined for the requests and responses among 387 the three actors that have been identified in the abstract mechanism. 388 The MIME types are composed of the basic data types defined in 389 Section 3.1. 391 3.1. Basic Data Formats 393 * The resource to be attested; 394 * A caller provided nonce; 395 * A locally sourced timestamp; 396 * The evidence produced by the Attester, and 397 * The attestation result produced by the Verifier. 399 These basic types are described by the following CDDL rules, which 400 reuse the eat-token definition from [I-D.ietf-rats-eat]. 402 3.1.1. Resource 404 An "ANY DEFINED BY"-like payload with type set to the original MIME 405 type, either Content-Type (HTTP) or Content-Format (CoAP), of the 406 resource representation. 408 resource-type = ( 409 typ tstr / uint, 410 val any, 411 ) 413 3.1.2. Nonce 415 nonce-type = bstr 417 3.1.3. Timestamp 419 timestamp-type = tdate / time 421 3.1.4. Evidence 423 An EAT token signed by the attester bound to the relying party 424 request and the attested resource state. 426 evidence-type = eat-token 428 3.1.5. Attestation Result 430 An EAT token signed by the verifier and bound to an evidence. 432 attestation-result-type = eat-token 434 3.2. Request and Response Payloads 436 3.2.1. Requesting an Attested Resource 438 MIME type "application/rats-attested-resource-request" 440 CoAP Content-Format: TBD-rats-attested-resource-request-CT 442 nonce-key = 0 / "n_X" 444 attested-resource-request = { 445 ? nonce-key => nonce-type, 446 } 448 This type is used in a POST request to an attested resource. 450 3.2.2. Attested Resource 452 MIME type "application/rats-attested-resource" 454 CoAP Content-Format: TBD-rats-attested-resource-CT 455 resource-key = 1 / "r" 456 t-A-key = 2 / "t_A" 457 evidence-key = 3 / "E" 458 attestation-result-key = 4 / "R" 460 attested-resource = { 461 resource-key => resource-type, 462 ? t-A-key => timestamp-type, 463 evidence-key => evidence-type, 464 ? attestation-result-key => attestation-result-type, 465 } 467 This type is used in a successful response to a request to an 468 attested resource endpoint. 470 Note that an attestation result is only present when the Passport 471 model is used. 473 Note also that the fact that the inner resource representation is 474 embedded within the "application/rats-attested-resource" envelope 475 suppresses the ability to do content negotiation on it, i.e., the 476 inner representation format is unilaterally chosen by the origin. 478 3.2.3. Request for Attestation Result 480 MIME type "application/rats-attestation-result-request" 482 CoAP Content-Format: TBD-rats-attestation-result-request-CT 484 n-Y-key = 5 / "n_Y" 486 attestation-result-request = { 487 ? n-Y-key => nonce-type, 488 evidence-key => evidence-type, 489 } 491 This type is used in a POST request to a verifier endpoint. 493 3.2.4. Verifier Response 495 MIME type "application/rats-attestation-result-response" 497 CoAP Content-Format: TBD-rats-attestation-result-response-CT 498 t-V-key = 6 / "n_Y" 500 attestation-result-response = { 501 ? t-V-key => timestamp-type, 502 attestation-result-key => attestation-result-type, 503 } 505 This type is used in a successful response to a POST request to a 506 verifier endpoint. 508 3.3. Interaction Model 510 (For now) we only describe a synchronous, RPC-like transaction model, 511 including the slight variant with a one-off trigger presented in 512 Section 2.3.4. 514 This might be not suited for devices that sit behind a NAT/firewall 515 box, or those that have to go through extended sleep cycles in order 516 to save energy. For this kind of devices, we assume in-network 517 support in the form of store-and-forward nodes (e.g., LwM2M queue 518 mode, specialised border routers, etc.). 520 3.3.1. Channel Security Considerations 522 Unless the channel can be considered free from passive and active 523 attackers at all times, all transactions are to be carried over a 524 secure transport (i.e., HTTPS or COAPS). 526 3.3.2. URLs 528 In the spirit of [RFC7320], no specific URL format is mandated. An 529 application is free to specify the URL scheme of its liking for the 530 exposed attested resources. 532 When an origin exposes the same underlying state both as nonce- and 533 timestamp-based resources, these are identified by two separate URIs. 535 The verifier function is exposed via an URI that accepts evidence in 536 form of "application/rats-attestation-result-request" typed requests 537 and returns attestation results in form of "application/rats- 538 attestation-result-response" typed responses. 540 3.3.3. Methods 542 As per usual REST conventions, the guiding principles are: 544 * POST is used for all requests involving a payload; 545 * GET is used for requests without a payload. 547 The only example of the latter is when retrieving an "Attested 548 Resource" using the timestamp-based freshness model. Any other 549 request uses POST. 551 3.3.3.1. Response Codes and Caching 553 The possible status codes are: 555 * HTTP 556 - 200 (OK) for successful GET. This response is cacheable; 557 origins can use Cache-Control (max-age) and ETag headers in 558 order to instruct on-path caches. 559 - 201 (Created) for a successful POST. This response is not 560 cacheable. 561 * CoAP 562 - 2.05 (Content) for successful GET. This response is cacheable; 563 origins can use Max-Age and ETag Options to instruct on-path 564 caches; 565 - 2.01 (Created) for successful POST. This response is not 566 cacheable. 568 Otherwise, a suitable error response (i.e., HTTP 4xx/5xx, CoAP 569 4.nn/5.nn) is returned. 571 3.3.4. Multicast Support 573 TODO (This is a CoAP only feature.) 575 3.3.5. Examples 577 A few examples are given to illustrate the different interaction 578 models using both CoAP and HTTP transports. 580 3.3.5.1. Background Check with Nonce Based Freshness 582 * RP - Attester (CoAP) 583 >> Request: 584 POST coap://device.example/my-attested-resource 585 Content-Format: TBD-application/rats-attested-resource-request-CT 586 Accept: application/rats-attested-resource 587 Payload: 588 { 589 "n_X": "bm9uY2Uh" 590 } 592 << Response: 593 2.01 Created 594 ETag: "xyzzy" 595 Content-format: TBD-application/rats-attested-resource-CT 596 Payload: 597 { 598 "r" : { 599 "typ": "text/plain", 600 "val": "foobar" 601 }, 602 "E": "eyJhbGciO...RfrKmTWk" 603 } 605 * RP - Verifier (HTTP) 607 >> Request: 608 POST /my-verify 609 Host: verifier.example 610 Content-Type: application/rats-attestation-result-request 611 Accept: application/rats-attestation-result-response 613 { 614 "E": "eyJhbGciO...RfrKmTWk" 615 } 617 << Response: 618 HTTP/1.1 201 Created 619 ETag: "abccb" 620 Content-format: application/rats-attestation-result-response 621 Payload: 622 { 623 "R": "eyJhbGciO...8j5EDGYc" 624 } 626 3.3.5.2. Background Check with Timestamp Based Freshness 628 * RP - Attester (CoAP) with POST 629 >> Request: 630 POST coap://device.example/my-attested-resource 631 Content-Format: TBD-application/rats-attested-resource-request-CT 632 Accept: TBD-application/rats-attested-resource-CT 633 Payload: 634 { } 636 << Response: 637 2.01 Created 638 ETag: "xyzzy" 639 Content-format: TBD-application/rats-attested-resource-CT 640 Payload: 641 { 642 "r" : { 643 "typ": "text/plain", 644 "val": "foobar" 645 }, 646 "t_A": "2020-04-01T21:02:31Z", 647 "E": "eyJhbGciO...z0ikw9Aa" 648 } 650 * RP - Attester (CoAP) with GET 652 >> Request: 653 GET coap://device.example/my-attested-resource 654 Accept: TBD-application/rats-attested-resource-CT 656 << Response: 657 2.05 Content 658 ETag: "xyzzy" 659 Max-Age: 3600 660 Content-format: TBD-application/rats-attested-resource-CT 661 Payload: 662 { 663 "r" : { 664 "typ": "text/plain", 665 "val": "foobar" 666 }, 667 "t_A": "2020-04-01T21:02:31Z", 668 "E": "eyJhbGciO...z0ikw9Aa" 669 } 671 * RP - Verifier (HTTP) is the same as Section 3.3.5.1. 673 3.3.5.3. Passport Model 675 * Attester - Verifier (CoAP) 676 >> Request: 677 POST coap://verifier.example/my-verify 678 Content-Format: application/rats-attestation-result-request 679 Accept: application/rats-attestation-result-response 680 Payload: 681 { 682 "E": "eyJhbGciO...RfrKmTWk" 683 } 685 << Response: 686 2.01 Created 687 ETag: "jkllk" 688 Content-format: application/rats-attestation-result-response 689 Payload: 690 { 691 "R": "eyJhbGciO...Z0IKW9aA" 692 } 694 * Relying Party - Attester (CoAP) with POST 696 >> Request: 697 POST coap://device.example/my-attested-resource 698 Content-Format: TBD-application/rats-attested-resource-request-CT 699 Accept: TBD-application/rats-attested-resource-CT 700 Payload: 701 { } 703 << Response: 704 2.01 Created 705 ETag: "qwerty" 706 Content-format: TBD-application/rats-attested-resource-CT 707 Payload: 708 { 709 "r": { 710 "type": "text/plain", 711 "val": "foobar" 712 }, 713 "t_A": "2020-04-01T21:02:31Z", 714 "E": "eyJhbGciO...RfrKmTWk", 715 "R": "eyJhbGciO...Z0IKW9aA" 716 } 718 * Relying Party - Attester (CoAP) with GET 719 >> Request: 720 GET coap://device.example/my-attested-resource 721 Accept: TBD-application/rats-attested-resource-CT 723 << Response: 724 2.05 Content 725 ETag: "qwerty" 726 Max-Age: 3600 727 Content-format: TBD-application/rats-attested-resource-CT 728 Payload: 729 { 730 "r": { 731 "type": "text/plain", 732 "val": "foobar" 733 }, 734 "t_A": "2020-04-01T21:02:31Z", 735 "E": "eyJhbGciO...RfrKmTWk", 736 "R": "eyJhbGciO...Z0IKW9aA" 737 } 739 4. Discovery 741 4.1. Resource Directory 743 The following describes the new link format attribute values needed 744 for registering attested resources as well as verification endpoints 745 to a Resource Directory [I-D.ietf-core-resource-directory]. 747 The same attribute values can be used by RD clients to discover 748 attestation related resources. 750 4.1.1. Attested Resource Registration 752 An attested resource is registered with: 754 * an interface description (if=) with value "rats.if.timestamp" or 755 "rats.if.nonce" depending on the supported freshness model, which 756 determines the access method (i.e., POST+nonce vs GET); 757 * a content format (ct=) with value "TBD-application/rats-attested- 758 resource-CT"; 759 * an inner content format (ict=) that reflects the "type" field of 760 the returned "resource"; 761 * a resource type (rt=) that reflects the nature of the inner 762 resource. 764 If a resource has both a "plain" and an "attested" variant, then the 765 link value corresponding to the "attested" resource can be associated 766 to its "plain" twin by means of the link relationship "attested- 767 variant". 769 TBD: Should we have rats.if.timestamp variants for GET and POST? 770 Alternative includes: 1) let the client probe and server return 771 405/4.05 if the requested variant is not supported; 2) add another 772 attribute that explicitly states which request methods are supported. 774 4.1.1.1. Examples 776 The following example shows a registrant endpoint with the name 777 "node1" registering an attested heart rate sensor resource to an RD. 779 The location /rd is an example RD location discovered in a previous 780 .well-known/core query. 782 >> Request: 783 POST /rd?ep=node1 HTTP/1.1 784 Host: rd.example 785 Content-Type: application/link-format 787 ; 788 if="rats.if.timestamp"; 789 rt="heart-rate-zoladz"; 790 ct=TBD-application/rats-attested-resource-CT; 791 ict=0 793 << Response: 794 HTTP/1.1 201 Created 795 Location: /rd/4520 797 The following example shows a registrant endpoint with the name 798 "node1" registering a temperature sensor resource along with its 799 attested twin to an RD. 801 The "attested-variant" link relation establishes the semantics of the 802 link between /sensors/temp and /sensors/attested-temp: the latter 803 being an attested version of the former. Note, in particular, that 804 the resource type (rt=) of the linked resource is inherited by the 805 attested twin. Missing an explicit inner content format (ict=) the 806 content type of the inner resource representation can be assumed to 807 be that of the linked resource. The interface description (if=) 808 "rats.if.nonce" says that the access to the attested resource happens 809 by supplying a nonce through a POST. 811 >> Request: 812 POST /rd?ep=node1 HTTP/1.1 813 Host: rd.example 814 Content-Type: application/link-format 816 ; 817 ct=41; 818 rt="temperature-c"; 819 if="sensor", 820 ; 821 anchor="/sensors/temp"; 822 rel="attested-variant"; 823 if="rats.if.nonce"; 824 ct=TBD-application/rats-attested-resource-CT; 825 ict=41 827 << Response: 828 HTTP/1.1 201 Created 829 Location: /rd/4521 831 4.1.2. Verifier Resource Registration 833 A Verifier resource is registered with: 835 * An "rt" with value "rats.verifier"; 836 * A "ct" with value "TBD-application/rats-attestation-result- 837 response-CT" 839 4.1.2.1. Examples 841 >> Request: 842 POST /rd?ep=node1 HTTP/1.1 843 Host: rd.example 844 Content-Type: application/link-format 846 ; 847 ct=application/rats-attestation-result-response; 848 rt="rats.verifier" 850 << Response: 851 HTTP/1.1 201 Created 852 Location: /rd/4522 854 5. IANA Considerations 856 TODO 858 6. Privacy Considerations 860 TODO 862 7. Security Considerations 864 7.1. Model Architecture for the Origin 866 The model architecture for the origin of the attested resource is 867 illustrated in Figure 7. The REST client (an user agent of a relying 868 party or verifier) interfaces directly with a REST front-end (a CoAP 869 or HTTP server stack) running in the Rich Execution Environment 870 (REE), for example a Linux operating system. The REST front-end is 871 paired with a back-end Trusted Application (TA) running in the 872 Trusted Execution Environment (TEE). The TA has exclusive control 873 over some "resource" (e.g., a sensor that feeds back into some kind 874 of critical infrastructure control system) and can talk to the 875 attestation service hosted inside the TEE to request EAT tokens. 877 In this model, it is critical that the attestation service can only 878 be used by the intended TA or, failing that, that the identity of the 879 calling TA can be securely proved to the relying party or verifier. 880 An example of the latter is the Client ID claim used in PSA 881 attestation [I-D.tschofenig-rats-psa-token]. 883 .-----------------.---------------------------. 884 | REE | TEE | 885 .--------. | .-----------. | .----------. .------. | 886 | REST |<--->| REST |<--->| back-end +->|resource| | 887 | client | | | front-end | | | TA | '------' | 888 '--------' | '-----------' | '-----+----' | 889 | | | | 890 | | v | 891 | | .-------------. | 892 | | | attestation | | 893 | | | service | | 894 | | '-------------' | 895 '-----------------'---------------------------' 897 Figure 7: Model Security Architecture 899 Acknowledgments 901 TBD 903 References 905 Normative References 907 [I-D.ietf-core-resource-directory] 908 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 909 Amsuess, "CoRE Resource Directory", Work in Progress, 910 Internet-Draft, draft-ietf-core-resource-directory-24, 9 911 March 2020, . 914 [I-D.ietf-rats-architecture] 915 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 916 W. Pan, "Remote Attestation Procedures Architecture", Work 917 in Progress, Internet-Draft, draft-ietf-rats-architecture- 918 04, 21 May 2020, . 921 [I-D.ietf-rats-eat] 922 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 923 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 924 Progress, Internet-Draft, draft-ietf-rats-eat-03, 20 925 February 2020, . 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, 930 DOI 10.17487/RFC2119, March 1997, 931 . 933 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 934 Protocol (HTTP/1.1): Message Syntax and Routing", 935 RFC 7230, DOI 10.17487/RFC7230, June 2014, 936 . 938 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 939 Application Protocol (CoAP)", RFC 7252, 940 DOI 10.17487/RFC7252, June 2014, 941 . 943 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 944 RFC 7320, DOI 10.17487/RFC7320, July 2014, 945 . 947 [RFC7641] Hartke, K., "Observing Resources in the Constrained 948 Application Protocol (CoAP)", RFC 7641, 949 DOI 10.17487/RFC7641, September 2015, 950 . 952 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 953 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 954 May 2017, . 956 Informative References 958 [Fielding] Fielding, R., "Architectural Styles and the Design of 959 Network-based Software Architectures", Ph.D. Dissertation, 960 University of California, Irvine, 2000, 961 . 964 [I-D.birkholz-rats-tuda] 965 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 966 "Time-Based Uni-Directional Attestation", Work in 967 Progress, Internet-Draft, draft-birkholz-rats-tuda-02, 9 968 March 2020, . 971 [I-D.tschofenig-rats-psa-token] 972 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. 973 Fossati, "Arm's Platform Security Architecture (PSA) 974 Attestation Token", Work in Progress, Internet-Draft, 975 draft-tschofenig-rats-psa-token-05, 6 March 2020, 976 . 979 Authors' Addresses 981 Adrian Shaw 982 arm 984 Email: Adrian.Shaw@arm.com 986 Hannes Tschofenig 987 arm 989 Email: Hannes.Tschofenig@arm.com 991 Sergei Trofimov 992 arm 994 Email: Sergei.Trofimov@arm.com 996 Simon Frost 997 arm 999 Email: Simon.Frost@arm.com 1000 Thomas Fossati 1001 arm 1003 Email: Thomas.Fossati@arm.com