idnits 2.17.1 draft-liu-opentrustprotocol-cbor-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 32 instances of too long lines in the document, the longest one being 40 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft Q. Fang 4 Intended status: Standards Track Alibaba Group 5 Expires: September 14, 2017 March 13, 2017 7 Open Trust Protocol CBOR Encoding 8 draft-liu-opentrustprotocol-cbor-00.txt 10 Abstract 12 This document specifies the Open Trust Protocol (OTrP) using RFC 7049 13 Concise Binary Object Representation(CBOR). 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Scenario of using CBOR . . . . . . . . . . . . . . . . . . . 3 57 3. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. API getTAInformation . . . . . . . . . . . . . . . . . . 3 59 3.2. OTrP Messages using CBOR Encoding . . . . . . . . . . . . 4 60 3.2.1. Request and Response Message Template . . . . . . . . 4 61 3.2.2. Signed Request and Response Message Structure . . . . 5 62 3.3. Detailed Messages Specification-8 . . . . . . . . . . . . 6 63 3.3.1. GetDeviceState-8.1 . . . . . . . . . . . . . . . . . 6 64 3.3.2. Security Domain Management-8.2 . . . . . . . . . . . 10 65 3.3.3. Trusted Application Management-8.3 . . . . . . . . . 13 66 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 4.1. Normative References . . . . . . . . . . . . . . . . . . 15 68 4.2. Informative References . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 This document uses CBOR to encode the operations in OTrP. The goal 74 is to improve the efficiency of information transmission in 75 bandwidth-constrained scenarios. This document will not change the 76 OTrP entity and the trust model. 78 This document will re-use the TA remote security mechanism as defined 79 in [draft-pei-opentrustprotocol]. 81 This document uses CBOR to encode the contents of JSON data as 82 defined in [draft-pei-opentrustprotocol]. 84 [draft-pei-opentrustprotocol]uses JOSE for JSON content encryption, 85 signatures and Message Authentication Code (MAC) operations. This 86 document uses the CBOR Object Encryption and Signing (COSE) standard 87 which does the similar thing for CBOR encoding format. 89 This document uses CDDL as defined in 90 [draft-greevenbosch-appsawg-cbor-cddl]to describe the CBOR content 91 defined in this document. 93 2. Scenario of using CBOR 95 In bandwidth constrained scenario, using JSON/JOSE to encode OTrP 96 message may not efficient. Using CBOR as encoding scheme can improve 97 the transmission efficiency. More use cases can be found in 98 [draft-liu-opentrustprotocol-usecase]. 100 3. OTrP Agent 102 3.1. API getTAInformation 104 If a new Client Application in the device that hasn't had TEE SP AIK 105 public key for the response verification, the application can contact 106 TSM first to do GetDeviceState, and TSM will return TEE SP AIK public 107 key to the app for this operation to proceed. 109 CBOR Message: 111 TAInformationTBS={ 112 taid : tstr, ;TA Identifier from the input 113 tsmid : tstr, ;TSM ID for the Security Domain where this TA resides 114 signercert : tstr, ;certificate data of the TA binary application's signer certificate 115 signercacerts : [*cacert], ;CA certificate data of the TA binary application's signer certificate 116 tsmcert : bstr, ;certificate data of the TSM that manages this TA 117 tsmcacerts : [*cacert] ;CA certificate data of the TSM that manages this TA 118 } 120 cacert=( 121 cacert : bstr 122 ) 124 98( 125 [ 126 / protected / h'' / 127 { 128 "reserved":false, 129 \ crit \ 2:[ 130 "reserved" 131 ] 132 } / , 133 / unprotected / {}, 134 / payload / 'the TAInformationTBS CBOR above.', 135 / signatures / [ 136 [ 137 / protected / h'' / { 138 \ alg \ 1:-7 \ ECDSA 256 \ 139 } / , 140 / unprotected / { 141 / kid / 4:'11' 142 }, 143 / signature / h'' 144 ] 145 ] 146 ] 147 ) 149 3.2. OTrP Messages using CBOR Encoding 151 When using CBOR as encoding method, the OTrP Protocol is composed of 152 a set of standard CBOR messages created by TSM to deliver SD and TA 153 management commands to a device and the device response messages 154 created by TEE. 156 3.2.1. Request and Response Message Template 158 An OTrP Request message uses the following format:(TBD) 159 { 160 "TBSRequest": { 161 162 } 163 } 165 A corresponding OTrP Response message will be as follows. 167 { 168 "TBSResponse": { 169 170 } 171 } 173 3.2.2. Signed Request and Response Message Structure 175 A signed request message will generally include only one signature 176 and uses the flattened COSE CBOR Serialization Syntax. 178 The following example is a general COSE object: 180 COSE_Sign = [ 181 Headers, 182 payload : bstr / nil, 183 signatures : [+ COSE_Signature] 184 ] 186 COSE_Signature = [ 187 Headers, 188 signature : bstr 189 ] 191 COSE_Encrypt = [ 192 Headers, 193 ciphertext : bstr / nil, 194 recipients : [+COSE_recipient] 195 ] 197 COSE_recipient = [ 198 Headers, 199 ciphertext : bstr / nil, 200 ? recipients : [+COSE_recipient] 201 ] 203 3.3. Detailed Messages Specification-8 205 For each message in the following sections all CBOR elements are 206 mandatory if it isn't explicitly indicated as optional. 208 3.3.1. GetDeviceState-8.1 210 3.3.1.1. GetDeviceStateRequest message-8.1.1 212 This is the first command that a TSM will query a device. This 213 command is triggered when a SP's Client Application contacts its TSM 214 to check whether the underlying device is ready for TA operations. 216 GetDeviceStateTBSRequest={ 217 ver : tstr, ;1.0 218 rid : tstr, ;Unique request ID 219 tid : tstr, ;transaction ID 220 ocspdat : bstr, ;OCSP stapling data of TSM certificate 221 icaocspdat : bstr, ;OCSP stapling data for TSM CA certificates 222 supportedsigalgs : bstr, ;comma separated signing algorithms 224 } 226 The request message consists of the following data elements: 228 ver - version of the message format 230 rid - a unique request ID generated by the TSM 232 tid - a unique transaction ID to trace request and response. This 233 can be from a prior transaction's tid field, and can be used in the 234 subsequent message exchanges in this TSM session. The combination of 235 rid and tid should be made unique. 237 ocspdat - OCSP stapling data for the TSM certificate. The TSM 238 provides OCSP data such that a recipient TEE can validate the 239 validity of the TSM certificate without making its own external OCSP 240 service call. This is a mandate field. 242 icaocspdat - OCSP stapling data for the intermediate CA certificates 243 of the TSM certificate up to the root. A TEE side can cache CA OCSP 244 data such that this value isn't needed in each call. 246 supportedsigalgs - an optional property to list the signing 247 algorithms that TSM is able to support. A recipient TEE should 248 choose algorithm in this list to sign its response message if this 249 property is present in a request. 251 The final request message is COSE signed message of the above raw 252 CBOR data with TSM's certificate. 254 98( 255 [ 256 / protected / h'', 257 / unprotected / {}, 258 / payload / 'GetDeviceStateTBSRequest CBOR above.', 259 / signatures / [ 260 [ 261 / protected / h'' / { 262 \ alg \ 1:-7 \ ECDSA 256 \ 263 } / , 264 / unprotected / { 265 / kid / 4:'11' 266 }, 267 / signature / h'signature contents signed by TSM private key' 268 ] 269 ] 270 ] 271 ) 273 3.3.1.2. Request processing requirements at a TEE-8.1.2 275 Upon receiving a request message GetDeviceStateRequest at a TEE, the 276 TEE must validate the request: 278 1. Validate CBOR message signing 280 2. Validate that the request TSM certificate is chained to a trusted 281 CA that the TEE embeds as its trust anchor. 283 * Cache the CA OCSP stapling data and certificate revocation check 284 status for other subsequent requests. 286 * A TEE can use its own clock time for the OCSP stapling data 287 validation. 289 3. Collect Firmware signed data 291 4. Collect SD information for the SD owned by this TSM 293 3.3.1.3. Post Conditions-8.1.4 295 The response message shall be encrypted where the encryption key 296 shall be a symmetric key that is wrapped by TSM's public key. 298 COSE_recipient holds the encrypted keys for recipients to encrypt the 299 respond message . 301 3.3.1.4. GetDeviceStateResponse message-8.1.5 303 The message has the following structure. 305 GetDeviceTEEStateTBSResponse={ 306 ver : 1.0, 307 status : pass/fail, 308 rid : tstr, ;the request ID from the request message 309 tid : tstr, ;transaction ID 310 signerreq : true/false ;whether TSM needs to send signer data again in subsequent messages 311 edsi : bstr ;Encrypted CBOR dsi information 313 } 315 The Device State Information (DSI) message consists of the following. 317 dsi={ 318 tfwdata : tfwdata, 319 tee : tee, 320 } 322 tfwdata={ 323 tbs : tstr, ;TFW to be signed data is the tid 324 cert : bstr, ;TFW certificate 325 sigalg : tstr, ;Signing method 326 sig : Tfw ;signed data 327 } 329 tee ={ 330 name : tstr, ; TEE name 331 ver : tstr, ; TEE version 332 cert : bstr, ;encoded TEE cert 333 cacert : bstr, ;array value of CA certificates up to the root CA 334 sdlist : sdlist, 335 teeaiklist: teeaiklist, 336 } 338 sdlist ={ 339 cnt: uint, ;Number of SD owned by this TSM 340 sd : sd 341 } 343 sd=[ 344 name : tstr, ; SD name 345 spid : tstr, ;SP owner ID of this SD 346 talist : talist, 347 ] 349 talist=[ 350 taid : tstr, ;TA application 351 taname : tstr, ;TA application friendly name optional 352 ] 354 teeaiklist=[*teeaiklist] 356 teeaiklist=[ 357 spaik : bstr, ; SP AIK public key, BASE64 encoded 358 spaiktype : tstr, ; RSA/ECC 359 spid : tstr, ; sp id 360 ] 362 TBD 364 3.3.1.5. TSM Processing Requirements-8.1.7 366 TBD 368 3.3.2. Security Domain Management-8.2 370 3.3.2.1. CreateSD-8.2.1 372 This command is typically preceded with GetDeviceState command that 373 has acquired the device information of the target device by the 374 TSM.TSM sends such a command to instruct a TEE to create a new 375 Security Domain for a SP. 377 3.3.2.1.1. CreateSDRequest Message-8.2.1.1 379 The request message for CreateSD has the following CBOR format. 381 CreateSDRequest={ 382 ver : 1.0, 383 rid : tstr, ;Unique request ID 384 tid : tstr, ;Transaction ID 385 tee : tstr, ; OCSP stapling data of TSM certificate 386 nextdsi : true/false, 387 dsihash : bstr, ;hash of DSI returned in the prior query 388 content : content, ;his piece of data will beencrypted 389 } 391 content ={ 392 spid : tstr, ;SP ID value 393 sdname : tstr, ;SD name for the domain to be created 394 spcert : tstr, ;SP certificate 395 tsmid : tstr, ;An identifiable attribute of the TSM certificate 396 did : bstr, ;SHA256 hash of the TEE cert 397 } 399 Following is the OTrP message template, the full request is signed 400 message over the CreateSDTBSRequest as follows. 402 98( 403 [ 404 / protected / h'', 405 / unprotected / {}, 406 / payload / 'CreateSDTBSRequest CBOR above.', 407 / signatures / [ 408 [ 409 / protected / h'a10126' / { 410 \ alg \ 1:-7 \ ECDSA 256 \ 411 } / , 412 / unprotected / { 413 / kid / 4:'11' 414 }, 415 / signature / 'signature contents signed by TSM private key' 416 ] 417 ] 418 ] 419 ) 421 3.3.2.1.2. Request processing requirements at a TEE-8.2.1.2 423 Upon receiving a request message CreateSDRequest at a TEE,the TEE 424 must validate a request. The process of Validate the CBOR request 425 message,Create action,Construct CreateSDResponse message,Deliver 426 response message and TSM process are same as described in 427 [draft-pei-opentrustprotocol] (8.2.1.2 Request processing 428 requirements at a TEE) 430 3.3.2.1.3. CreateSDResponse Message-8.2.1.3 432 The response message for a CreateSDRequest contains the following 433 content. 435 CreateSDTBSResponse={ 436 ver : 1.0, ;version 437 status : bstr, ;operation result 438 rid : tstr, ;Unique request ID 439 tid : tstr, ;Transaction ID 440 content : content, ;this piece of data will beencrypted 441 } 443 content ={ 444 reason : bstr, ;failure reason detail 445 did : bstr, ;the device id received from the request 446 sdname : tstr, ;SD name for the domain to be created 447 teespaik : bstr, ;SP certificate 448 dsi : bstr, ;Updated TEE state, including all SD owned by this TSM 449 } 451 3.3.2.2. UpdateSD-8.2.2 453 3.3.2.2.1. UpdateSDRequest Message-8.2.2.1 455 TBD 457 3.3.2.2.2. Request processing requirements at a TEE-8.2.2.1 459 TBD 461 3.3.2.2.3. UpdateSDResponse Message-8.2.2.3 463 TBD 465 3.3.2.3. DeleteSD--8.2.3 467 3.3.2.3.1. DeleteSDRequest Message-8.2.3.1 469 TBD 471 3.3.2.3.2. Request processing requirements at a TEE-8.2.3.2 473 TBD 475 3.3.2.3.3. DeleteSDResponse Message-8.2.3.3 477 TBD 479 3.3.3. Trusted Application Management-8.3 481 The following three TA management commands will be supported. 483 o InstallTA - provision a TA by TSM 485 o UpdateTA - update a TA by TSM 487 o DeleteTA - remove TA registration information with a SD, remove TA 488 binary from TEE, remove all TA related data in TEE 490 3.3.3.1. InstallTA--8.3.1 492 3.3.3.1.1. InstallTARequest Message-8.3.1.1 494 The request message for InstallTA has the following format. 496 InstallTATBSRequest={ 497 ver : 1.0, 498 rid : tstr, ;Unique request ID 499 tid : tstr, ;Transaction ID 500 tee : tstr, ; OCSP stapling data of TSM certificate 501 nextdsi : true/false, 502 dsihash : bstr, ;hash of DSI returned in the prior query 503 content : content, ;this piece of data will beencrypted 504 encrypted_ta : encrypted_ta ;encrypted_ta 505 } 507 content ={ 508 tsmid : tstr, ;TSM ID previously assigned to the SD 509 spid : tstr, ;SPID value 510 sdname : tstr, ;SD name for the domain to install the TA 511 spcert : bstr, ;SP certificate 512 taid : tstr, ;TA identifier 513 } 515 encrypted_ta={ 516 key : bstr, ;A 256-bit symmetric key encrypted by TEEspaik public key 517 iv : bstr, ;hex of 16 random bytes 518 alg : tstr, ;encryption algoritm. AESCBC by default. 519 ciphertadata : bstr, ;encrypted TA binary data 520 cipherpdata : bstr, ;encrypted TA personalization data 521 } 523 3.3.3.1.2. InstallTAResponse Message-8.3.1.2 525 InstallTATBSResponse={ 526 ver : 1.0, 527 status : bstr, ;operation result 528 rid : tstr, ;Unique request ID 529 tid : tstr, ;Transaction ID 530 content : content, ;this piece of data will be encrypted 531 } 533 content ={ 534 reason : bstr, ;failure reason detail 535 did : bstr, ;the device id received from the request 536 dsi : tstr, ;the device id hash 537 } 539 The InstallTAResponse message: 541 TBD 543 3.3.3.2. UpdateTA--8.3.2 545 3.3.3.2.1. UpdateTARequest Message-8.3.2.1 547 TBD 549 3.3.3.2.2. UpdateTAResponse Message-8.3.2.2 551 TBD 553 3.3.3.3. DeleteTA--8.3.3 555 3.3.3.3.1. DeleteTARequest Message-8.3.3.1 557 TBD 559 3.3.3.3.2. Request processing requirements at a TEE-8.3.3.2 561 TBD 563 3.3.3.3.3. DeleteTAResponse Message-8.3.3.3 565 TBD 567 3.3.3.4. UpdateTA--8.3.2 569 4. References 571 4.1. Normative References 573 [draft-pei-opentrustprotocol] 574 "The Open Trust Protocol (OTrP)", January 2017. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, 579 . 581 4.2. Informative References 583 [draft-greevenbosch-appsawg-cbor-cddl] 584 "CBOR data definition language (CDDL): a notational 585 convention to express CBOR data structures", September 586 2016. 588 [draft-liu-opentrustprotocol-usecase] 589 "Use case of Open Trust Protocol", March 2016. 591 Authors' Addresses 593 Dapeng Liu 594 Alibaba Group 595 Beijing 596 Beijing 598 Phone: +86-1391788933 599 Email: maxpassion@gmail.com 601 Qiang Fang 602 Alibaba Group 603 Beijing 604 Beijing 606 Phone: +86-15210569677 607 Email: qiangwu.fq@alibaba-inc.com