idnits 2.17.1 draft-ietf-rats-uccs-01.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (13 July 2021) is 1010 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) == Missing Reference: 'RFCthis' is mentioned on line 276, but not defined ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-10 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-14 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track J. O'Donoghue 5 Expires: 14 January 2022 Qualcomm Technologies Inc. 6 N. Cam-Winget 7 Cisco Systems 8 C. Bormann 9 Universität Bremen TZI 10 13 July 2021 12 A CBOR Tag for Unprotected CWT Claims Sets 13 draft-ietf-rats-uccs-01 15 Abstract 17 CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the 18 protection afforded by wrapping them into COSE, as is required for a 19 true CWT. This specification defines a CBOR tag for such unprotected 20 CWT Claims Sets (UCCS) and discusses conditions for its proper use. 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 January 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Characteristics of a Secure Channel . . . . . . . . . . . . . 4 59 3.1. UCCS and Remote ATtestation procedureS (RATS) . . . . . . 5 60 3.2. Privacy Preserving Channels . . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 5.1. General Considerations . . . . . . . . . . . . . . . . . 7 64 5.2. AES-CBC_MAC . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.3. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.4. AES-CCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.5. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 6.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 A CBOR Web Token (CWT) as specified by [RFC8392] is always wrapped in 77 a CBOR Object Signing and Encryption (COSE, [RFC8152]) envelope. 78 COSE provides -- amongst other things -- the end-to-end data origin 79 authentication and integrity protection employed by RFC 8392 and 80 optional encryption for CWTs. Under the right circumstances 81 (Section 3), though, a signature providing proof for authenticity and 82 integrity can be provided through the transfer protocol and thus 83 omitted from the information in a CWT without compromising the 84 intended goal of authenticity and integrity. In other words, if 85 communicating parties have a pre-existing security association they 86 can reuse it to provide authenticity and integrity for their 87 messages, enabling the basic principle of using resources 88 parsimoniously. Specifically, if a mutually Secured Channel is 89 established between two remote peers, and if that Secure Channel 90 provides the required properties (as discussed below), it is possible 91 to omit the protection provided by COSE, creating a use case for 92 unprotected CWT Claims Sets. Similarly, if there is one-way 93 authentication, the party that did not authenticate may be in a 94 position to send authentication information through this channel that 95 allows the already authenticated party to authenticate the other 96 party. 98 This specification allocates a CBOR tag to mark Unprotected CWT 99 Claims Sets (UCCS) as such and discusses conditions for its proper 100 use in the scope of Remote ATtestation procedureS (RATS) and the 101 conveyance of Evidence from an Attester to a Verifier. 103 This specification does not change [RFC8392]: A true CWT does not 104 make use of the tag allocated here; the UCCS tag is an alternative to 105 using COSE protection and a CWT tag. Consequently, within the well- 106 defined scope of a secured channel, it can be acceptable and economic 107 to use the contents of a CWT without its COSE container and tag it 108 with a UCCS CBOR tag for further processing within that scope -- or 109 to use the contents of a UCCS CBOR tag for building a CWT to be 110 signed by some entity that can vouch for those contents. 112 1.1. Terminology 114 The term Claim is used as in [RFC7519]. 116 The terms Claim Key, Claim Value, and CWT Claims Set are used as in 117 [RFC8392]. 119 The terms Attester, Attesting Environment and Verifier are used as in 120 [I-D.ietf-rats-architecture]. 122 UCCS: Unprotected CWT Claims Set(s); CBOR map(s) of Claims as 123 defined by the CWT Claims Registry that are composed of pairs of 124 Claim Keys and Claim Values. 126 Secure Channel: A protected communication channel between two peers 127 that can ensure the same qualities associated for UCCS conveyance 128 as CWT conveyance without any additional protection. 130 All terms referenced or defined in this section are capitalized in 131 the remainder of this document. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. Example Use Cases 141 Use cases involving the conveyance of Claims, in particular, remote 142 attestation procedures (RATS, see [I-D.ietf-rats-architecture]) 143 require a standardized data definition and encoding format that can 144 be transferred and transported using different communication 145 channels. As these are Claims, [RFC8392] is a suitable format. 146 However, the way these Claims are secured depends on the deployment, 147 the security capabilities of the device, as well as their software 148 stack. For example, a Claim may be securely stored and conveyed 149 using a device's Trusted Execution Environment (TEE, see 150 [I-D.ietf-teep-architecture]) or especially in some resource 151 constrained environments, the same process that provides the secure 152 communication transport is also the delegate to compose the Claim to 153 be conveyed. Whether it is a transfer or transport, a Secure Channel 154 is presumed to be used for conveying such UCCS. The following 155 sections further describe the RATS usage scenario and corresponding 156 requirements for UCCS deployment. 158 3. Characteristics of a Secure Channel 160 A Secure Channel for the conveyance of UCCS needs to provide the 161 security properties that would otherwise be provided by COSE for a 162 CWT. In this regard, UCCS is similar in security considerations to 163 JWTs [RFC8725] using the algorithm "none". RFC 8725 states: 165 | [...] if a JWT is cryptographically protected end-to-end by a 166 | transport layer, such as TLS using cryptographically current 167 | algorithms, there may be no need to apply another layer of 168 | cryptographic protections to the JWT. In such cases, the use of 169 | the "none" algorithm can be perfectly acceptable. 171 The security considerations discussed, e.g., in Sections 2.1, 3.1, 172 and 3.2 of [RFC8725] apply in an analogous way to the use of UCCS as 173 elaborated on in this document. 175 Secure Channels are often set up in a handshake protocol that 176 mutually derives a session key, where the handshake protocol 177 establishes the (identity and thus) authenticity of one or both ends 178 of the communication. The session key can then be used to provide 179 confidentiality and integrity of the transfer of information inside 180 the Secure Channel. A well-known example of a such a Secure Channel 181 setup protocol is the TLS [RFC8446] handshake; the TLS record 182 protocol can then be used for secure conveyance. 184 As UCCS were initially created for use in Remote ATtestation 185 procedureS (RATS) Secure Channels, the following subsection provides 186 a discussion of their use in these channels. Where other 187 environments are intended to be used to convey UCCS, similar 188 considerations need to be documented before UCCS can be used. 190 3.1. UCCS and Remote ATtestation procedureS (RATS) 192 For the purposes of this section, the Verifier is the receiver of the 193 UCCS and the Attester is the provider of the UCCS. 195 Secure Channels can be transient in nature. For the purposes of this 196 specification, the mechanisms used to establish a Secure Channel are 197 out of scope. 199 As a minimum requirement in the scope of RATS Claims, the Verifier 200 MUST authenticate the Attester as part of the establishment of the 201 Secure Channel. Furthermore, the channel MUST provide integrity of 202 the communication from the Attester to the Verifier. If 203 confidentiality is also required, the receiving side needs to be 204 authenticated as well; this can be achieved if the Verifier and the 205 Attester mutually authenticate when establishing the Secure Channel. 207 The extent to which a Secure Channel can provide assurances that UCCS 208 originate from a trustworthy attesting environment depends on the 209 characteristics of both the cryptographic mechanisms used to 210 establish the channel and the characteristics of the attesting 211 environment itself. 213 A Secure Channel established or maintained using weak cryptography 214 may not provide the assurance required by a relying party of the 215 authenticity and integrity of the UCCS. 217 Ultimately, it is up to the Verifier's policy to determine whether to 218 accept a UCCS from the Attester and to the type of Secure Channel it 219 must negotiate. While the security considerations of the 220 cryptographic algorithms used are similar to COSE, the considerations 221 of the secure channel should also adhere to the policy configured at 222 each of the Attester and the Verifier. However, the policy controls 223 and definitions are out of scope for this document. 225 Where the security assurance required of an attesting environment by 226 a relying party requires it, the attesting environment may be 227 implemented using techniques designed to provide enhanced protection 228 from an attacker wishing to tamper with or forge UCCS. A possible 229 approach might be to implement the attesting environment in a 230 hardened environment such as a TEE [I-D.ietf-teep-architecture] or a 231 TPM [TPM2]. 233 When UCCS emerge from the Secure Channel and into the Verifier, the 234 security properties of the Secure Channel no longer apply and UCCS 235 have the same properties as any other unprotected data in the 236 Verifier environment. If the Verifier subsequently forwards UCCS, 237 they are treated as though they originated within the Verifier. 239 As with EATs nested in other EATs (Section 3.20.1.2 of 240 [I-D.ietf-rats-eat]), the Secure Channel does not endorse fully 241 formed CWTs transferred through it. Effectively, the COSE envelope 242 of a CWT shields the CWT Claims Set from the endorsement of the 243 Secure Channel. (Note that EAT might add a nested UCCS Claim, and 244 this statement does not apply to UCCS nested into UCCS, only to fully 245 formed CWTs) 247 3.2. Privacy Preserving Channels 249 A Secure Channel which preserves the privacy of the Attester may 250 provide security properties equivalent to COSE, but only inside the 251 life-span of the session established. In general, a Verifier cannot 252 correlate UCCS received in different sessions from the same attesting 253 environment based on the cryptographic mechanisms used when a privacy 254 preserving Secure Channel is employed. 256 In the case of a Remote Attestation, the attester must consider 257 whether any UCCS it returns over a privacy preserving Secure Channel 258 compromises the privacy in unacceptable ways. As an example, the use 259 of the EAT UEID [I-D.ietf-rats-eat] Claim in UCCS over a privacy 260 preserving Secure Channel allows a verifier to correlate UCCS from a 261 single attesting environment across many Secure Channel sessions. 262 This may be acceptable in some use-cases (e.g. if the attesting 263 environment is a physical sensor in a factory) and unacceptable in 264 others (e.g. if the attesting environment is a device belonging to a 265 child). 267 4. IANA Considerations 269 In the registry [IANA.cbor-tags], IANA is requested to allocate the 270 tag in Table 1 from the FCFS space, with the present document as the 271 specification reference. 273 +========+===========+======================================+ 274 | Tag | Data Item | Semantics | 275 +========+===========+======================================+ 276 | TBD601 | map | Unprotected CWT Claims Set [RFCthis] | 277 +--------+-----------+--------------------------------------+ 279 Table 1: Values for Tags 281 5. Security Considerations 283 The security considerations of [RFC8949] apply. The security 284 considerations of [RFC8392] need to be applied analogously, replacing 285 the role of COSE with that of the Secured Channel. 287 Section 3 discusses security considerations for Secure Channels, in 288 which UCCS might be used. This document provides the CBOR tag 289 definition for UCCS and a discussion on security consideration for 290 the use of UCCS in Remote ATtestation procedureS (RATS). Uses of 291 UCCS outside the scope of RATS are not covered by this document. The 292 UCCS specification - and the use of the UCCS CBOR tag, 293 correspondingly - is not intended for use in a scope where a scope- 294 specific security consideration discussion has not been conducted, 295 vetted and approved for that use. 297 5.1. General Considerations 299 Implementations of Secure Channels are often separate from the 300 application logic that has security requirements on them. Similar 301 security considerations to those described in 302 [I-D.ietf-cose-rfc8152bis-struct] for obtaining the required levels 303 of assurance include: 305 * Implementations need to provide sufficient protection for private 306 or secret key material used to establish or protect the Secure 307 Channel. 309 * Using a key for more than one algorithm can leak information about 310 the key and is not recommended. 312 * An algorithm used to establish or protect the Secure Channel may 313 have limits on the number of times that a key can be used without 314 leaking information about the key. 316 The Verifier needs to ensure that the management of key material used 317 establish or protect the Secure Channel is acceptable. This may 318 include factors such as: 320 * Ensuring that any permissions associated with key ownership are 321 respected in the establishment of the Secure Channel. 323 * Cryptographic algorithms are used appropriately. 325 * Key material is used in accordance with any usage restrictions 326 such as freshness or algorithm restrictions. 328 * Ensuring that appropriate protections are in place to address 329 potential traffic analysis attacks. 331 5.2. AES-CBC_MAC 333 * A given key should only be used for messages of fixed or known 334 length. 336 * Different keys should be used for authentication and encryption 337 operations. 339 * A mechanism to ensure that IV cannot be modified is required. 341 Section 3.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 342 explanation of these considerations. 344 5.3. AES-GCM 346 * The key and nonce pair are unique for every encrypted message. 348 * The maximum number of messages to be encrypted for a given key is 349 not exceeded. 351 Section 4.1.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 352 explanation of these considerations. 354 5.4. AES-CCM 356 * The key and nonce pair are unique for every encrypted message. 358 * The maximum number of messages to be encrypted for a given block 359 cipher is not exceeded. 361 * The number of messages both successfully and unsuccessfully 362 decrypted is used to determine when rekeying is required. 364 Section 4.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 365 explanation of these considerations. 367 5.5. ChaCha20 and Poly1305 369 * The nonce is unique for every encrypted message. 371 * The number of messages both successfully and unsuccessfully 372 decrypted is used to determine when rekeying is required. 374 Section 4.3.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 375 explanation of these considerations. 377 6. References 379 6.1. Normative References 381 [IANA.cbor-tags] 382 IANA, "Concise Binary Object Representation (CBOR) Tags", 383 . 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 391 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 392 . 394 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 395 RFC 8152, DOI 10.17487/RFC8152, July 2017, 396 . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 403 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 404 May 2018, . 406 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 407 Current Practices", BCP 225, RFC 8725, 408 DOI 10.17487/RFC8725, February 2020, 409 . 411 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 412 Representation (CBOR)", STD 94, RFC 8949, 413 DOI 10.17487/RFC8949, December 2020, 414 . 416 6.2. Informative References 418 [I-D.ietf-cose-rfc8152bis-algs] 419 Schaad, J., "CBOR Object Signing and Encryption (COSE): 420 Initial Algorithms", Work in Progress, Internet-Draft, 421 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 422 . 425 [I-D.ietf-cose-rfc8152bis-struct] 426 Schaad, J., "CBOR Object Signing and Encryption (COSE): 427 Structures and Process", Work in Progress, Internet-Draft, 428 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 429 . 432 [I-D.ietf-rats-architecture] 433 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 434 W. Pan, "Remote Attestation Procedures Architecture", Work 435 in Progress, Internet-Draft, draft-ietf-rats-architecture- 436 12, 23 April 2021, . 439 [I-D.ietf-rats-eat] 440 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 441 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 442 Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 June 443 2021, . 446 [I-D.ietf-teep-architecture] 447 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 448 "Trusted Execution Environment Provisioning (TEEP) 449 Architecture", Work in Progress, Internet-Draft, draft- 450 ietf-teep-architecture-14, 22 February 2021, 451 . 454 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 455 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 456 . 458 [TPM2] "Trusted Platform Module Library Specification, Family 459 "2.0", Level 00, Revision 01.59 ed., Trusted Computing 460 Group", 2019. 462 Appendix A. Example 464 The example CWT Claims Set from Appendix A.1 of [RFC8392] can be 465 turned into an UCCS by enclosing it with a tag number TBD601: 467 ( 468 { 469 / iss / 1: "coap://as.example.com", 470 / sub / 2: "erikw", 471 / aud / 3: "coap://light.example.com", 472 / exp / 4: 1444064944, 473 / nbf / 5: 1443944944, 474 / iat / 6: 1443944944, 475 / cti / 7: h'0b71' 476 } 477 ) 479 Authors' Addresses 481 Henk Birkholz 482 Fraunhofer SIT 483 Rheinstrasse 75 484 64295 Darmstadt 485 Germany 487 Email: henk.birkholz@sit.fraunhofer.de 489 Jeremy O'Donoghue 490 Qualcomm Technologies Inc. 491 279 Farnborough Road 492 Farnborough 493 GU14 7LS 494 United Kingdom 496 Email: jodonogh@qti.qualcomm.com 498 Nancy Cam-Winget 499 Cisco Systems 500 3550 Cisco Way 501 San Jose, CA 95134 502 United States of America 504 Email: ncamwing@cisco.com 506 Carsten Bormann 507 Universität Bremen TZI 508 Postfach 330440 509 D-28359 Bremen 510 Germany 511 Phone: +49-421-218-63921 512 Email: cabo@tzi.org