draft-ietf-rats-uccs-00.txt | draft-ietf-rats-uccs-01.txt | |||
---|---|---|---|---|
RATS Working Group H. Birkholz | RATS Working Group H. Birkholz | |||
Internet-Draft Fraunhofer SIT | Internet-Draft Fraunhofer SIT | |||
Intended status: Standards Track J. O'Donoghue | Intended status: Standards Track J. O'Donoghue | |||
Expires: 20 November 2021 Qualcomm Technologies Inc. | Expires: 14 January 2022 Qualcomm Technologies Inc. | |||
N. Cam-Winget | N. Cam-Winget | |||
Cisco Systems | Cisco Systems | |||
C. Bormann | C. Bormann | |||
Universitaet Bremen TZI | Universität Bremen TZI | |||
19 May 2021 | 13 July 2021 | |||
A CBOR Tag for Unprotected CWT Claims Sets | A CBOR Tag for Unprotected CWT Claims Sets | |||
draft-ietf-rats-uccs-00 | draft-ietf-rats-uccs-01 | |||
Abstract | Abstract | |||
CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the | CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the | |||
protection afforded by wrapping them into COSE, as is required for a | protection afforded by wrapping them into COSE, as is required for a | |||
true CWT. This specification defines a CBOR tag for such unprotected | true CWT. This specification defines a CBOR tag for such unprotected | |||
CWT Claims Sets (UCCS) and discusses conditions for its proper use. | CWT Claims Sets (UCCS) and discusses conditions for its proper use. | |||
Discussion Venues | ||||
This note is to be removed before publishing as an RFC. | ||||
Discussion of this document takes place on the mailing list | ||||
(rats@ietf.org), which is archived at | ||||
https://mailarchive.ietf.org/arch/browse/rats/. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://github.com/ietf-rats-wg/draft-ietf-rats-uccs. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 20 November 2021. | This Internet-Draft will expire on 14 January 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Motivation and Requirements . . . . . . . . . . . . . . . . . 4 | 2. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Characteristics of a Secure Channel . . . . . . . . . . . . . 4 | 3. Characteristics of a Secure Channel . . . . . . . . . . . . . 4 | |||
3.1. UCCS and Remote ATtestation procedureS (RATS) . . . . . . 5 | 3.1. UCCS and Remote ATtestation procedureS (RATS) . . . . . . 5 | |||
3.2. Privacy Preserving Channels . . . . . . . . . . . . . . . 6 | 3.2. Privacy Preserving Channels . . . . . . . . . . . . . . . 6 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
5.1. General Considerations . . . . . . . . . . . . . . . . . 7 | 5.1. General Considerations . . . . . . . . . . . . . . . . . 7 | |||
5.2. AES-CBC_MAC . . . . . . . . . . . . . . . . . . . . . . . 7 | 5.2. AES-CBC_MAC . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.3. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.3. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.4. AES-CCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.4. AES-CCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.5. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 8 | 5.5. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 8 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . 9 | 6.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 | Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
A CBOR Web Token (CWT) as specified by [RFC8392] is always wrapped in | A CBOR Web Token (CWT) as specified by [RFC8392] is always wrapped in | |||
a CBOR Object Signing and Encryption (COSE, [RFC8152]) envelope. | a CBOR Object Signing and Encryption (COSE, [RFC8152]) envelope. | |||
COSE provides -- amongst other things -- the integrity protection | COSE provides -- amongst other things -- the end-to-end data origin | |||
mandated by RFC 8392 and optional encryption for CWTs. Under the | authentication and integrity protection employed by RFC 8392 and | |||
right circumstances, though, a signature providing proof for | optional encryption for CWTs. Under the right circumstances | |||
authenticity and integrity can be provided through the transfer | (Section 3), though, a signature providing proof for authenticity and | |||
protocol and thus omitted from the information in a CWT without | integrity can be provided through the transfer protocol and thus | |||
compromising the intended goal of authenticity and integrity. If a | omitted from the information in a CWT without compromising the | |||
mutually Secured Channel is established between two remote peers, and | intended goal of authenticity and integrity. In other words, if | |||
if that Secure Channel provides the required properties (as discussed | communicating parties have a pre-existing security association they | |||
below), it is possible to omit the protection provided by COSE, | can reuse it to provide authenticity and integrity for their | |||
creating a use case for unprotected CWT Claims Sets. Similarly, if | messages, enabling the basic principle of using resources | |||
there is one-way authentication, the party that did not authenticate | parsimoniously. Specifically, if a mutually Secured Channel is | |||
may be in a position to send authentication information through this | established between two remote peers, and if that Secure Channel | |||
channel that allows the already authenticated party to authenticate | provides the required properties (as discussed below), it is possible | |||
the other party. | to omit the protection provided by COSE, creating a use case for | |||
unprotected CWT Claims Sets. Similarly, if there is one-way | ||||
authentication, the party that did not authenticate may be in a | ||||
position to send authentication information through this channel that | ||||
allows the already authenticated party to authenticate the other | ||||
party. | ||||
This specification allocates a CBOR tag to mark Unprotected CWT | This specification allocates a CBOR tag to mark Unprotected CWT | |||
Claims Sets (UCCS) as such and discusses conditions for its proper | Claims Sets (UCCS) as such and discusses conditions for its proper | |||
use in the scope of Remote ATtestation procedureS (RATS) and the | use in the scope of Remote ATtestation procedureS (RATS) and the | |||
conveyance of Evidence from an Attester to a Verifier. | conveyance of Evidence from an Attester to a Verifier. | |||
This specification does not change [RFC8392]: A true CWT does not | This specification does not change [RFC8392]: A true CWT does not | |||
make use of the tag allocated here; the UCCS tag is an alternative to | make use of the tag allocated here; the UCCS tag is an alternative to | |||
using COSE protection and a CWT tag. Consequently, in a well-defined | using COSE protection and a CWT tag. Consequently, within the well- | |||
scope, it might be acceptable to use the contents of a CWT without | defined scope of a secured channel, it can be acceptable and economic | |||
its COSE container and tag it with a UCCS CBOR tag for further | to use the contents of a CWT without its COSE container and tag it | |||
processing -- or to use the contents of a UCCS CBOR tag for building | with a UCCS CBOR tag for further processing within that scope -- or | |||
a CWT to be signed by some entity that can vouch for those contents. | to use the contents of a UCCS CBOR tag for building a CWT to be | |||
signed by some entity that can vouch for those contents. | ||||
1.1. Terminology | 1.1. Terminology | |||
The term Claim is used as in [RFC8725]. | The term Claim is used as in [RFC7519]. | |||
The terms Claim Key, Claim Value, and CWT Claims Set are used as in | The terms Claim Key, Claim Value, and CWT Claims Set are used as in | |||
[RFC8392]. | [RFC8392]. | |||
The terms Attester, Attesting Environment and Verifier are used as in | The terms Attester, Attesting Environment and Verifier are used as in | |||
[I-D.ietf-rats-architecture]. | [I-D.ietf-rats-architecture]. | |||
UCCS: Unprotected CWT Claims Set(s); CBOR map(s) of Claims as | UCCS: Unprotected CWT Claims Set(s); CBOR map(s) of Claims as | |||
defined by the CWT Claims Registry that are composed of pairs of | defined by the CWT Claims Registry that are composed of pairs of | |||
Claim Keys and Claim Values. | Claim Keys and Claim Values. | |||
skipping to change at page 4, line 5 ¶ | skipping to change at page 4, line 5 ¶ | |||
All terms referenced or defined in this section are capitalized in | All terms referenced or defined in this section are capitalized in | |||
the remainder of this document. | the remainder of this document. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Motivation and Requirements | 2. Example Use Cases | |||
Use cases involving the conveyance of Claims, in particular, remote | Use cases involving the conveyance of Claims, in particular, remote | |||
attestation procedures (RATS, see [I-D.ietf-rats-architecture]) | attestation procedures (RATS, see [I-D.ietf-rats-architecture]) | |||
require a standardized data definition and encoding format that can | require a standardized data definition and encoding format that can | |||
be transferred and transported using different communication | be transferred and transported using different communication | |||
channels. As these are Claims, [RFC8392] is a suitable format. | channels. As these are Claims, [RFC8392] is a suitable format. | |||
However, the way these Claims are secured depends on the deployment, | However, the way these Claims are secured depends on the deployment, | |||
the security capabilities of the device, as well as their software | the security capabilities of the device, as well as their software | |||
stack. For example, a Claim may be securely stored and conveyed | stack. For example, a Claim may be securely stored and conveyed | |||
using a device's Trusted Execution Environment (TEE, see | using a device's Trusted Execution Environment (TEE, see | |||
skipping to change at page 4, line 29 ¶ | skipping to change at page 4, line 29 ¶ | |||
be conveyed. Whether it is a transfer or transport, a Secure Channel | be conveyed. Whether it is a transfer or transport, a Secure Channel | |||
is presumed to be used for conveying such UCCS. The following | is presumed to be used for conveying such UCCS. The following | |||
sections further describe the RATS usage scenario and corresponding | sections further describe the RATS usage scenario and corresponding | |||
requirements for UCCS deployment. | requirements for UCCS deployment. | |||
3. Characteristics of a Secure Channel | 3. Characteristics of a Secure Channel | |||
A Secure Channel for the conveyance of UCCS needs to provide the | A Secure Channel for the conveyance of UCCS needs to provide the | |||
security properties that would otherwise be provided by COSE for a | security properties that would otherwise be provided by COSE for a | |||
CWT. In this regard, UCCS is similar in security considerations to | CWT. In this regard, UCCS is similar in security considerations to | |||
JWTs [RFC8725] using the algorithm "none". RFC 8725 states: "if a | JWTs [RFC8725] using the algorithm "none". RFC 8725 states: | |||
JWT is cryptographically protected end-to-end by a transport layer, | ||||
such as TLS using cryptographically current algorithms, there may be | | [...] if a JWT is cryptographically protected end-to-end by a | |||
no need to apply another layer of cryptographic protections to the | | transport layer, such as TLS using cryptographically current | |||
JWT. In such cases, the use of the "none" algorithm can be perfectly | | algorithms, there may be no need to apply another layer of | |||
acceptable.". Analogously, the considerations discussed in Sections | | cryptographic protections to the JWT. In such cases, the use of | |||
2.1, 3.1, and 3.2 of RFC 8725 apply to the use of UCCS as elaborated | | the "none" algorithm can be perfectly acceptable. | |||
on in this document. | ||||
The security considerations discussed, e.g., in Sections 2.1, 3.1, | ||||
and 3.2 of [RFC8725] apply in an analogous way to the use of UCCS as | ||||
elaborated on in this document. | ||||
Secure Channels are often set up in a handshake protocol that | Secure Channels are often set up in a handshake protocol that | |||
mutually derives a session key, where the handshake protocol | mutually derives a session key, where the handshake protocol | |||
establishes the authenticity of one of both ends of the | establishes the (identity and thus) authenticity of one or both ends | |||
communication. The session key can then be used to provide | of the communication. The session key can then be used to provide | |||
confidentiality and integrity of the transfer of information inside | confidentiality and integrity of the transfer of information inside | |||
the Secure Channel. A well-known example of a such a Secure Channel | the Secure Channel. A well-known example of a such a Secure Channel | |||
setup protocol is the TLS [RFC8446] handshake; the TLS record | setup protocol is the TLS [RFC8446] handshake; the TLS record | |||
protocol can then be used for secure conveyance. | protocol can then be used for secure conveyance. | |||
As UCCS were initially created for use in Remote ATtestation | As UCCS were initially created for use in Remote ATtestation | |||
procedureS (RATS) Secure Channels, the following subsection provides | procedureS (RATS) Secure Channels, the following subsection provides | |||
a discussion of their use in these channels. Where other | a discussion of their use in these channels. Where other | |||
environments are intended to be used to convey UCCS, similar | environments are intended to be used to convey UCCS, similar | |||
considerations need to be documented before UCCS can be used. | considerations need to be documented before UCCS can be used. | |||
skipping to change at page 5, line 18 ¶ | skipping to change at page 5, line 24 ¶ | |||
UCCS and the Attester is the provider of the UCCS. | UCCS and the Attester is the provider of the UCCS. | |||
Secure Channels can be transient in nature. For the purposes of this | Secure Channels can be transient in nature. For the purposes of this | |||
specification, the mechanisms used to establish a Secure Channel are | specification, the mechanisms used to establish a Secure Channel are | |||
out of scope. | out of scope. | |||
As a minimum requirement in the scope of RATS Claims, the Verifier | As a minimum requirement in the scope of RATS Claims, the Verifier | |||
MUST authenticate the Attester as part of the establishment of the | MUST authenticate the Attester as part of the establishment of the | |||
Secure Channel. Furthermore, the channel MUST provide integrity of | Secure Channel. Furthermore, the channel MUST provide integrity of | |||
the communication from the Attester to the Verifier. If | the communication from the Attester to the Verifier. If | |||
confidentiality is also required, the receiving side needs to be be | confidentiality is also required, the receiving side needs to be | |||
authenticated as well, i.e., the Verifier and the Attester SHOULD | authenticated as well; this can be achieved if the Verifier and the | |||
mutually authenticate when establishing the Secure Channel. | Attester mutually authenticate when establishing the Secure Channel. | |||
The extent to which a Secure Channel can provide assurances that UCCS | The extent to which a Secure Channel can provide assurances that UCCS | |||
originate from a trustworthy attesting environment depends on the | originate from a trustworthy attesting environment depends on the | |||
characteristics of both the cryptographic mechanisms used to | characteristics of both the cryptographic mechanisms used to | |||
establish the channel and the characteristics of the attesting | establish the channel and the characteristics of the attesting | |||
environment itself. | environment itself. | |||
A Secure Channel established or maintained using weak cryptography | A Secure Channel established or maintained using weak cryptography | |||
may not provide the assurance required by a relying party of the | may not provide the assurance required by a relying party of the | |||
authenticity and integrity of the UCCS. | authenticity and integrity of the UCCS. | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 11 ¶ | |||
approach might be to implement the attesting environment in a | approach might be to implement the attesting environment in a | |||
hardened environment such as a TEE [I-D.ietf-teep-architecture] or a | hardened environment such as a TEE [I-D.ietf-teep-architecture] or a | |||
TPM [TPM2]. | TPM [TPM2]. | |||
When UCCS emerge from the Secure Channel and into the Verifier, the | When UCCS emerge from the Secure Channel and into the Verifier, the | |||
security properties of the Secure Channel no longer apply and UCCS | security properties of the Secure Channel no longer apply and UCCS | |||
have the same properties as any other unprotected data in the | have the same properties as any other unprotected data in the | |||
Verifier environment. If the Verifier subsequently forwards UCCS, | Verifier environment. If the Verifier subsequently forwards UCCS, | |||
they are treated as though they originated within the Verifier. | they are treated as though they originated within the Verifier. | |||
As with EATs nested in other EATs (Section 3.12.1.2 of | As with EATs nested in other EATs (Section 3.20.1.2 of | |||
[I-D.ietf-rats-eat]), the Secure Channel does not endorse fully | [I-D.ietf-rats-eat]), the Secure Channel does not endorse fully | |||
formed CWTs transferred through it. Effectively, the COSE envelope | formed CWTs transferred through it. Effectively, the COSE envelope | |||
of a CWT shields the CWT Claims Set from the endorsement of the | of a CWT shields the CWT Claims Set from the endorsement of the | |||
Secure Channel. (Note that EAT might add a nested UCCS Claim, and | Secure Channel. (Note that EAT might add a nested UCCS Claim, and | |||
this statement does not apply to UCCS nested into UCCS, only to fully | this statement does not apply to UCCS nested into UCCS, only to fully | |||
formed CWTs) | formed CWTs) | |||
3.2. Privacy Preserving Channels | 3.2. Privacy Preserving Channels | |||
A Secure Channel which preserves the privacy of the Attester may | A Secure Channel which preserves the privacy of the Attester may | |||
skipping to change at page 6, line 49 ¶ | skipping to change at page 7, line 7 ¶ | |||
+========+===========+======================================+ | +========+===========+======================================+ | |||
| Tag | Data Item | Semantics | | | Tag | Data Item | Semantics | | |||
+========+===========+======================================+ | +========+===========+======================================+ | |||
| TBD601 | map | Unprotected CWT Claims Set [RFCthis] | | | TBD601 | map | Unprotected CWT Claims Set [RFCthis] | | |||
+--------+-----------+--------------------------------------+ | +--------+-----------+--------------------------------------+ | |||
Table 1: Values for Tags | Table 1: Values for Tags | |||
5. Security Considerations | 5. Security Considerations | |||
The security considerations of [RFC7049] and [RFC8392] apply. | The security considerations of [RFC8949] apply. The security | |||
considerations of [RFC8392] need to be applied analogously, replacing | ||||
the role of COSE with that of the Secured Channel. | ||||
Section 3 discusses security considerations for Secure Channels, in | Section 3 discusses security considerations for Secure Channels, in | |||
which UCCS might be used. This documents provides the CBOR tag | which UCCS might be used. This document provides the CBOR tag | |||
definition for UCCS and a discussion on security consideration for | definition for UCCS and a discussion on security consideration for | |||
the use of UCCS in Remote ATtestation procedureS (RATS). Uses of | the use of UCCS in Remote ATtestation procedureS (RATS). Uses of | |||
UCCS outside the scope of RATS are not covered by this document. The | UCCS outside the scope of RATS are not covered by this document. The | |||
UCCS specification - and the use of the UCCS CBOR tag, | UCCS specification - and the use of the UCCS CBOR tag, | |||
correspondingly - is not intended for use in a scope where a scope- | correspondingly - is not intended for use in a scope where a scope- | |||
specific security consideration discussion has not been conducted, | specific security consideration discussion has not been conducted, | |||
vetted and approved for that use. | vetted and approved for that use. | |||
5.1. General Considerations | 5.1. General Considerations | |||
skipping to change at page 8, line 10 ¶ | skipping to change at page 8, line 18 ¶ | |||
5.2. AES-CBC_MAC | 5.2. AES-CBC_MAC | |||
* A given key should only be used for messages of fixed or known | * A given key should only be used for messages of fixed or known | |||
length. | length. | |||
* Different keys should be used for authentication and encryption | * Different keys should be used for authentication and encryption | |||
operations. | operations. | |||
* A mechanism to ensure that IV cannot be modified is required. | * A mechanism to ensure that IV cannot be modified is required. | |||
[I-D.ietf-cose-rfc8152bis-algs], Section 3.2.1 contains a detailed | Section 3.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed | |||
explanation of these considerations. | explanation of these considerations. | |||
5.3. AES-GCM | 5.3. AES-GCM | |||
* The key and nonce pair are unique for every encrypted message. | * The key and nonce pair are unique for every encrypted message. | |||
* The maximum number of messages to be encrypted for a given key is | * The maximum number of messages to be encrypted for a given key is | |||
not exceeded. | not exceeded. | |||
[I-D.ietf-cose-rfc8152bis-algs], Section 4.1.1 contains a detailed | Section 4.1.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed | |||
explanation of these considerations. | explanation of these considerations. | |||
5.4. AES-CCM | 5.4. AES-CCM | |||
* The key and nonce pair are unique for every encrypted message. | * The key and nonce pair are unique for every encrypted message. | |||
* The maximum number of messages to be encrypted for a given block | * The maximum number of messages to be encrypted for a given block | |||
cipher is not exceeded. | cipher is not exceeded. | |||
* The number of messages both successfully and unsuccessfully | * The number of messages both successfully and unsuccessfully | |||
decrypted is used to determine when rekeying is required. | decrypted is used to determine when rekeying is required. | |||
[I-D.ietf-cose-rfc8152bis-algs], Section 4.2.1 constains a detailed | Section 4.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed | |||
explanation of these considerations. | explanation of these considerations. | |||
5.5. ChaCha20 and Poly1305 | 5.5. ChaCha20 and Poly1305 | |||
* The nonce is unique for every encrypted message. | * The nonce is unique for every encrypted message. | |||
* The number of messages both successfully and unsuccessfully | * The number of messages both successfully and unsuccessfully | |||
decrypted is used to determine when rekeying is required. | decrypted is used to determine when rekeying is required. | |||
[I-D.ietf-cose-rfc8152bis-algs], Section 4.3.1 contains a detailed | Section 4.3.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed | |||
explanation of these considerations. | explanation of these considerations. | |||
6. References | 6. References | |||
6.1. Normative References | 6.1. Normative References | |||
[IANA.cbor-tags] | [IANA.cbor-tags] | |||
IANA, "Concise Binary Object Representation (CBOR) Tags", | IANA, "Concise Binary Object Representation (CBOR) Tags", | |||
<http://www.iana.org/assignments/cbor-tags>. | <http://www.iana.org/assignments/cbor-tags>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | |||
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | |||
October 2013, <https://www.rfc-editor.org/rfc/rfc7049>. | <https://www.rfc-editor.org/info/rfc7519>. | |||
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | |||
RFC 8152, DOI 10.17487/RFC8152, July 2017, | RFC 8152, DOI 10.17487/RFC8152, July 2017, | |||
<https://www.rfc-editor.org/rfc/rfc8152>. | <https://www.rfc-editor.org/info/rfc8152>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | |||
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | |||
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>. | May 2018, <https://www.rfc-editor.org/info/rfc8392>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | ||||
<https://www.rfc-editor.org/rfc/rfc8446>. | ||||
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best | [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best | |||
Current Practices", BCP 225, RFC 8725, | Current Practices", BCP 225, RFC 8725, | |||
DOI 10.17487/RFC8725, February 2020, | DOI 10.17487/RFC8725, February 2020, | |||
<https://www.rfc-editor.org/rfc/rfc8725>. | <https://www.rfc-editor.org/info/rfc8725>. | |||
[TPM2] "Trusted Platform Module Library Specification, Family | [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
“2.0”, Level 00, Revision 01.59 ed., Trusted Computing | Representation (CBOR)", STD 94, RFC 8949, | |||
Group", 2019. | DOI 10.17487/RFC8949, December 2020, | |||
<https://www.rfc-editor.org/info/rfc8949>. | ||||
6.2. Informative References | 6.2. Informative References | |||
[I-D.ietf-cose-rfc8152bis-algs] | [I-D.ietf-cose-rfc8152bis-algs] | |||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | Schaad, J., "CBOR Object Signing and Encryption (COSE): | |||
Initial Algorithms", Work in Progress, Internet-Draft, | Initial Algorithms", Work in Progress, Internet-Draft, | |||
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, | draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, | |||
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- | <https://www.ietf.org/archive/id/draft-ietf-cose- | |||
algs-12>. | rfc8152bis-algs-12.txt>. | |||
[I-D.ietf-cose-rfc8152bis-struct] | [I-D.ietf-cose-rfc8152bis-struct] | |||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | Schaad, J., "CBOR Object Signing and Encryption (COSE): | |||
Structures and Process", Work in Progress, Internet-Draft, | Structures and Process", Work in Progress, Internet-Draft, | |||
draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, | draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, | |||
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- | <https://www.ietf.org/archive/id/draft-ietf-cose- | |||
struct-15>. | rfc8152bis-struct-15.txt>. | |||
[I-D.ietf-rats-architecture] | [I-D.ietf-rats-architecture] | |||
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and | Birkholz, H., Thaler, D., Richardson, M., Smith, N., and | |||
W. Pan, "Remote Attestation Procedures Architecture", Work | W. Pan, "Remote Attestation Procedures Architecture", Work | |||
in Progress, Internet-Draft, draft-ietf-rats-architecture- | in Progress, Internet-Draft, draft-ietf-rats-architecture- | |||
12, 23 April 2021, <https://tools.ietf.org/html/draft- | 12, 23 April 2021, <https://www.ietf.org/archive/id/draft- | |||
ietf-rats-architecture-12>. | ietf-rats-architecture-12.txt>. | |||
[I-D.ietf-rats-eat] | [I-D.ietf-rats-eat] | |||
Mandyam, G., Lundblade, L., Ballesteros, M., and J. | Mandyam, G., Lundblade, L., Ballesteros, M., and J. | |||
O'Donoghue, "The Entity Attestation Token (EAT)", Work in | O'Donoghue, "The Entity Attestation Token (EAT)", Work in | |||
Progress, Internet-Draft, draft-ietf-rats-eat-09, 7 March | Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 June | |||
2021, | 2021, <https://www.ietf.org/archive/id/draft-ietf-rats- | |||
<https://tools.ietf.org/html/draft-ietf-rats-eat-09>. | eat-10.txt>. | |||
[I-D.ietf-teep-architecture] | [I-D.ietf-teep-architecture] | |||
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, | Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, | |||
"Trusted Execution Environment Provisioning (TEEP) | "Trusted Execution Environment Provisioning (TEEP) | |||
Architecture", Work in Progress, Internet-Draft, draft- | Architecture", Work in Progress, Internet-Draft, draft- | |||
ietf-teep-architecture-14, 22 February 2021, | ietf-teep-architecture-14, 22 February 2021, | |||
<https://tools.ietf.org/html/draft-ietf-teep-architecture- | <https://www.ietf.org/archive/id/draft-ietf-teep- | |||
14>. | architecture-14.txt>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | ||||
<https://www.rfc-editor.org/info/rfc8446>. | ||||
[TPM2] "Trusted Platform Module Library Specification, Family | ||||
"2.0", Level 00, Revision 01.59 ed., Trusted Computing | ||||
Group", 2019. | ||||
Appendix A. Example | Appendix A. Example | |||
The example CWT Claims Set from Appendix A.1 of [RFC8392] can be | The example CWT Claims Set from Appendix A.1 of [RFC8392] can be | |||
turned into an UCCS by enclosing it with a tag number TBD601: | turned into an UCCS by enclosing it with a tag number TBD601: | |||
<TBD601>( | <TBD601>( | |||
{ | { | |||
/ iss / 1: "coap://as.example.com", | / iss / 1: "coap://as.example.com", | |||
/ sub / 2: "erikw", | / sub / 2: "erikw", | |||
skipping to change at page 11, line 4 ¶ | skipping to change at page 11, line 18 ¶ | |||
/ sub / 2: "erikw", | / sub / 2: "erikw", | |||
/ aud / 3: "coap://light.example.com", | / aud / 3: "coap://light.example.com", | |||
/ exp / 4: 1444064944, | / exp / 4: 1444064944, | |||
/ nbf / 5: 1443944944, | / nbf / 5: 1443944944, | |||
/ iat / 6: 1443944944, | / iat / 6: 1443944944, | |||
/ cti / 7: h'0b71' | / cti / 7: h'0b71' | |||
} | } | |||
) | ) | |||
Authors' Addresses | Authors' Addresses | |||
Henk Birkholz | Henk Birkholz | |||
Fraunhofer SIT | Fraunhofer SIT | |||
Rheinstrasse 75 | Rheinstrasse 75 | |||
Darmstadt | 64295 Darmstadt | |||
Germany | ||||
Email: henk.birkholz@sit.fraunhofer.de | Email: henk.birkholz@sit.fraunhofer.de | |||
Jeremy O'Donoghue | Jeremy O'Donoghue | |||
Qualcomm Technologies Inc. | Qualcomm Technologies Inc. | |||
279 Farnborough Road | 279 Farnborough Road | |||
Farnborough | Farnborough | |||
GU14 7LS | GU14 7LS | |||
United Kingdom | United Kingdom | |||
skipping to change at page 11, line 29 ¶ | skipping to change at page 11, line 45 ¶ | |||
Nancy Cam-Winget | Nancy Cam-Winget | |||
Cisco Systems | Cisco Systems | |||
3550 Cisco Way | 3550 Cisco Way | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
United States of America | United States of America | |||
Email: ncamwing@cisco.com | Email: ncamwing@cisco.com | |||
Carsten Bormann | Carsten Bormann | |||
Universitaet Bremen TZI | Universität Bremen TZI | |||
Bibliothekstrasse 1 | Postfach 330440 | |||
28369 Bremen | D-28359 Bremen | |||
Germany | Germany | |||
Phone: +49-421-218-63921 | Phone: +49-421-218-63921 | |||
Email: cabo@tzi.de | Email: cabo@tzi.org | |||
End of changes. 41 change blocks. | ||||
94 lines changed or deleted | 100 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |