draft-hoeglund-core-oscore-key-limits-00.txt | draft-hoeglund-core-oscore-key-limits-01.txt | |||
---|---|---|---|---|
CoRE Working Group R. Hoeglund | CoRE Working Group R. Höglund | |||
Internet-Draft M. Tiloca | Internet-Draft M. Tiloca | |||
Updates: 8613 (if approved) RISE AB | Updates: 8613 (if approved) RISE AB | |||
Intended status: Standards Track February 19, 2021 | Intended status: Standards Track 12 July 2021 | |||
Expires: August 23, 2021 | Expires: 13 January 2022 | |||
AEAD Key Usage Limits in OSCORE | Key Update for OSCORE | |||
draft-hoeglund-core-oscore-key-limits-00 | draft-hoeglund-core-oscore-key-limits-01 | |||
Abstract | Abstract | |||
Object Security for Constrained RESTful Environments (OSCORE) uses | Object Security for Constrained RESTful Environments (OSCORE) uses | |||
AEAD algorithms to ensure confidentiality and integrity of exchanged | AEAD algorithms to ensure confidentiality and integrity of exchanged | |||
messages. Due to known issues allowing forgery attacks against AEAD | messages. Due to known issues allowing forgery attacks against AEAD | |||
algorithms, limits should be followed on the number of times a | algorithms, limits should be followed on the number of times a | |||
specific key is used for encryption or decryption. This document | specific key is used for encryption or decryption. This document | |||
defines how two peers using OSCORE must take these limits into | defines how two OSCORE peers must follow these limits and what steps | |||
account and what steps they must take to preserve the security of | they must take to preserve the security of their communications. | |||
their communications. Therefore, this document updates RFC8613. | Therefore, this document updates RFC8613. Furthermore, this document | |||
specifies a lightweight method that two peers can use to update their | ||||
keying material and establish a new OSCORE Security Context. | ||||
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 August 23, 2021. | This Internet-Draft will expire on 13 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 | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
(https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | Please review these documents carefully, as they describe your rights | |||
to this document. Code Components extracted from this document must | and restrictions with respect to this document. Code Components | |||
include Simplified BSD License text as described in Section 4.e of | extracted from this document must include Simplified BSD License text | |||
the Trust Legal Provisions and are provided without warranty as | as described in Section 4.e of the Trust Legal Provisions and are | |||
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. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 3 | 2. AEAD Key Usage Limits in OSCORE . . . . . . . . . . . . . . . 3 | |||
2.1. Limits for 'q' and 'v' . . . . . . . . . . . . . . . . . 4 | 2.1. Problem Overview . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Additional Information in the Security Context . . . . . . . 4 | 2.1.1. Limits for 'q' and 'v' . . . . . . . . . . . . . . . 4 | |||
4. OSCORE Messages Processing . . . . . . . . . . . . . . . . . 5 | 2.2. Additional Information in the Security Context . . . . . 6 | |||
4.1. Protecting a Request or a Response . . . . . . . . . . . 5 | 2.2.1. Common Context . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. Verifying a Request or a Response . . . . . . . . . . . . 6 | 2.2.2. Sender Context . . . . . . . . . . . . . . . . . . . 7 | |||
5. Methods for Rekeying OSCORE . . . . . . . . . . . . . . . . . 6 | 2.2.3. Recipient Context . . . . . . . . . . . . . . . . . . 7 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 2.3. OSCORE Messages Processing . . . . . . . . . . . . . . . 7 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 2.3.1. Protecting a Request or a Response . . . . . . . . . 8 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3.2. Verifying a Request or a Response . . . . . . . . . . 8 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.4. Current methods for Rekeying OSCORE . . . . . . . . . . . 8 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 3. New Method for Rekeying OSCORE . . . . . . . . . . . . . . . 10 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 8 | 3.1. Extensions to the OSCORE Option . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.2. Update Function . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3. Establishment of the New OSCORE Security Context . . . . 14 | ||||
3.4. Retention Policies . . . . . . . . . . . . . . . . . . . 18 | ||||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | ||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | ||||
5.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . . 19 | ||||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
6.1. Normative References . . . . . . . . . . . . . . . . . . 19 | ||||
6.2. Informative References . . . . . . . . . . . . . . . . . 20 | ||||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
1. Introduction | 1. Introduction | |||
Object Security for Constrained RESTful Environments (OSCORE) | Object Security for Constrained RESTful Environments (OSCORE) | |||
[RFC8613] provides end-to-end protection of CoAP [RFC7252] messages | [RFC8613] provides end-to-end protection of CoAP [RFC7252] messages | |||
at the application-layer, ensuring message confidentiality and | at the application-layer, ensuring message confidentiality and | |||
integrity, replay protection, as well as binding of response to | integrity, replay protection, as well as binding of response to | |||
request between a sender and a recipient. | request between a sender and a recipient. | |||
In particular, OSCORE uses AEAD algorithms to provide confidentiality | In particular, OSCORE uses AEAD algorithms to provide confidentiality | |||
skipping to change at page 3, line 5 ¶ | skipping to change at page 3, line 16 ¶ | |||
properties of the AEAD algorithm, such as message confidentiality and | properties of the AEAD algorithm, such as message confidentiality and | |||
integrity, e.g. by performing a message forgery attack. The original | integrity, e.g. by performing a message forgery attack. The original | |||
OSCORE specification [RFC8613] does not consider such limits. | OSCORE specification [RFC8613] does not consider such limits. | |||
This document updates [RFC8613] and defines when a peer must stop | This document updates [RFC8613] and defines when a peer must stop | |||
using an OSCORE Security Context shared with another peer, due to the | using an OSCORE Security Context shared with another peer, due to the | |||
reached key usage limits. When this happens, the two peers have to | reached key usage limits. When this happens, the two peers have to | |||
establish a new Security Context with new keying material, in order | establish a new Security Context with new keying material, in order | |||
to continue their secure communication with OSCORE. | to continue their secure communication with OSCORE. | |||
Furthermore, this document specifies a lightweight method that the | ||||
two peers can use in order to update their current keying material | ||||
and establish a new OSCORE Security Context. | ||||
1.1. Terminology | 1.1. Terminology | |||
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 BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Readers are expected to be familiar with the terms and concepts | Readers are expected to be familiar with the terms and concepts | |||
related to the CoAP [RFC7252] and OSCORE [RFC8613] protocols. | related to the CoAP [RFC7252] and OSCORE [RFC8613] protocols. | |||
2. Problem Overview | 2. AEAD Key Usage Limits in OSCORE | |||
The following sections details how key usage limits for AEAD | ||||
algorithms must be considered when using OSCORE. It covers specific | ||||
limits for common AEAD algorithms used with OSCORE; necessary | ||||
additions to the OSCORE Security Context, updates to the OSCORE | ||||
message processing, and existing methods for rekeying OSCORE. | ||||
2.1. Problem Overview | ||||
The OSCORE security protocol [RFC8613] uses AEAD algorithms to | The OSCORE security protocol [RFC8613] uses AEAD algorithms to | |||
provide integrity and confidentiality of messages, as exchanged | provide integrity and confidentiality of messages, as exchanged | |||
between two peers sharing an OSCORE Security Context. | between two peers sharing an OSCORE Security Context. | |||
When processing messages with OSCORE, each peer should follow | When processing messages with OSCORE, each peer should follow | |||
specific limits as to the number of times it uses a specific key. | specific limits as to the number of times it uses a specific key. | |||
This applies separately to the Sender Key used to encrypt outgoing | This applies separately to the Sender Key used to encrypt outgoing | |||
messages, and to the Recipient Key used to decrypt and verify | messages, and to the Recipient Key used to decrypt and verify | |||
incoming protected messages. | incoming protected messages. | |||
Exceeding these limits may allow an adversary to break the security | Exceeding these limits may allow an adversary to break the security | |||
properties of the AEAD algorithm, such as message confidentiality and | properties of the AEAD algorithm, such as message confidentiality and | |||
integrity, e.g. by performing a message forgery attack. | integrity, e.g. by performing a message forgery attack. | |||
The following refers to the two parameters 'q' and 'v' introduced in | The following refers to the two parameters 'q' and 'v' introduced in | |||
[I-D.irtf-cfrg-aead-limits], to use when deploying an AEAD algorithm. | [I-D.irtf-cfrg-aead-limits], to use when deploying an AEAD algorithm. | |||
o 'q': this parameter has as value the number of messages protected | * 'q': this parameter has as value the number of messages protected | |||
with a specific key, i.e. the number of times the AEAD algorithm | with a specific key, i.e. the number of times the AEAD algorithm | |||
has been invoked to encrypt data with that key. | has been invoked to encrypt data with that key. | |||
o 'v': this parameter has as value the number of alleged forgery | * 'v': this parameter has as value the number of alleged forgery | |||
attempts that have been made against a specific key, i.e. the | attempts that have been made against a specific key, i.e. the | |||
amount of failed decryptions that has been done with the AEAD | amount of failed decryptions that has been done with the AEAD | |||
algorithm for that key. | algorithm for that key. | |||
When a peer uses OSCORE: | When a peer uses OSCORE: | |||
o The key used to protect outgoing messages is its Sender Key, in | * The key used to protect outgoing messages is its Sender Key, in | |||
its Sender Context. | its Sender Context. | |||
o The key used to decrypt and verify incoming messages is its | * The key used to decrypt and verify incoming messages is its | |||
Recipient Key, in its Recipient Context. | Recipient Key, in its Recipient Context. | |||
Both keys are derived as part of the establishment of the OSCORE | Both keys are derived as part of the establishment of the OSCORE | |||
Security Context, as defined in Section 3.2 of [RFC8613]. | Security Context, as defined in Section 3.2 of [RFC8613]. | |||
As mentioned above, exceeding specific limits for the 'q' or 'v' | As mentioned above, exceeding specific limits for the 'q' or 'v' | |||
value can weaken the security properties of the AEAD algorithm used, | value can weaken the security properties of the AEAD algorithm used, | |||
thus compromising secure communication requirements. | thus compromising secure communication requirements. | |||
Therefore, in order to preserve the security of the used AEAD | Therefore, in order to preserve the security of the used AEAD | |||
algorithm, OSCORE has to observe limits for the 'q' and 'v' values, | algorithm, OSCORE has to observe limits for the 'q' and 'v' values, | |||
throughout the lifetime of the used AEAD keys. | throughout the lifetime of the used AEAD keys. | |||
2.1. Limits for 'q' and 'v' | 2.1.1. Limits for 'q' and 'v' | |||
Recommendations for setting limits for the maximum 'q' and 'v' value | Formulas for calculating the security levels as Integrity Advantage | |||
are defined in [I-D.irtf-cfrg-aead-limits]. | (IA) and Confidentiality Advantage (CA) probabilities, are presented | |||
in [I-D.irtf-cfrg-aead-limits]. These formulas take as input | ||||
specific values for 'q' and 'v' (see section Section 2.1) and for | ||||
'l', i.e., the maximum length of each message (in cipher blocks). | ||||
In particular, Figure 1 shows the limits given for AES-CCM-16-64-128, | For the algorithms that can be used as AEAD Algorithm for OSCORE | |||
which is the mandatory to implement AEAD algorithm for OSCORE. | shows in Figure 1, the key property to achieve is having IA and CA | |||
values which are no larger than p = 2^-64, which will ensure a safe | ||||
security level for the AEAD Algorithm. This can be entailed by using | ||||
the values q = 2^20, v = 2^20, and l = 2^8, that this document | ||||
recommends to use for these algorithms. | ||||
q <= sqrt((p * 2^126) / l^2) | Figure 1 shows the resulting IA and CA probabilities enjoyed by the | |||
considered algorithms, when taking the value of 'q', 'v' and 'l' | ||||
above as input to the formulas defined in | ||||
[I-D.irtf-cfrg-aead-limits]. | ||||
v * 2^64 + (2l * (v + q))^2 <= p * 2^128 | +------------------------+----------------+----------------+ | |||
| Algorithm name | IA probability | CA probability | | ||||
|------------------------+----------------+----------------| | ||||
| AEAD_AES_128_CCM | 2^-68 | 2^-70 | | ||||
| AEAD_AES_128_GCM | 2^-99 | 2^-89 | | ||||
| AEAD_AES_256_GCM | 2^-99 | 2^-89 | | ||||
| AEAD_CHACHA20_POLY1305 | 2^-75 | - | | ||||
+------------------------+----------------+----------------+ | ||||
Figure 1: AES-CCM-16-64-128 limits | Figure 1: Probabilities for algorithms based on chosen q, v and l | |||
values. | ||||
Considering the values p_q = 2^-60 and p_v = 2^-57 defined in | For the AEAD_AES_128_CCM_8 algorithm when used as AEAD Algorithm for | |||
[I-D.ietf-tls-dtls13], as well as l=1024, this gives the following | OSCORE, larger IA and CA values are achieved, depending on the value | |||
values for the limits of 'q' and 'v'. | of 'q', 'v' and 'l'. Figure 2 shows the resulting IA and CA | |||
probabilities enjoyed by AEAD_AES_128_CCM_8, when taking different | ||||
values of 'q', 'v' and 'l' as input to the formulas defined in | ||||
[I-D.irtf-cfrg-aead-limits]. | ||||
q <= sqrt(((2^-60) * 2^126) / 1024^2) | As shown in Figure 2, it is especially possible to achieve the lowest | |||
IA = 2^-54 and a good CA = 2^-70 by considering the largest possible | ||||
value of the (q, v, l) triplet equal to (2^20, 2^10, 2^8), while | ||||
still keeping a good security level. Note that the value of 'l' does | ||||
not impact on IA, while CA displays good values for every considered | ||||
value of 'l'. | ||||
q <= 2^23 | When AEAD_AES_128_CCM_8 is used as AEAD Algorithm for OSCORE, this | |||
document recommends to use the triplet (q, v, l) = (2^20, 2^10, 2^8) | ||||
and to never use a triplet (q, v, l) such that the resulting IA and | ||||
CA probabilities are higher than 2^-54. | ||||
v * 2^64 + (2*1024 * (v + 2^23))^2 <= 2^-57 * 2^128 | +-----------------------+----------------+----------------+ | |||
| 'q', 'v' and 'l' | IA probability | CA probability | | ||||
|-----------------------+----------------+----------------| | ||||
| q=2^20, v=2^20, l=2^8 | 2^-44 | 2^-70 | | ||||
| q=2^15, v=2^20, l=2^8 | 2^-44 | 2^-80 | | ||||
| q=2^10, v=2^20, l=2^8 | 2^-44 | 2^-90 | | ||||
| q=2^20, v=2^15, l=2^8 | 2^-49 | 2^-70 | | ||||
| q=2^15, v=2^15, l=2^8 | 2^-49 | 2^-80 | | ||||
| q=2^10, v=2^15, l=2^8 | 2^-49 | 2^-90 | | ||||
| q=2^20, v=2^10, l=2^8 | 2^-54 | 2^-70 | | ||||
| q=2^15, v=2^10, l=2^8 | 2^-54 | 2^-80 | | ||||
| q=2^10, v=2^10, l=2^8 | 2^-54 | 2^-90 | | ||||
|-----------------------+----------------+----------------| | ||||
| q=2^20, v=2^20, l=2^6 | 2^-44 | 2^-74 | | ||||
| q=2^15, v=2^20, l=2^6 | 2^-44 | 2^-84 | | ||||
| q=2^10, v=2^20, l=2^6 | 2^-44 | 2^-94 | | ||||
| q=2^20, v=2^15, l=2^6 | 2^-49 | 2^-74 | | ||||
| q=2^15, v=2^15, l=2^6 | 2^-49 | 2^-84 | | ||||
| q=2^10, v=2^15, l=2^6 | 2^-49 | 2^-94 | | ||||
| q=2^20, v=2^10, l=2^6 | 2^-54 | 2^-74 | | ||||
| q=2^15, v=2^10, l=2^6 | 2^-54 | 2^-84 | | ||||
| q=2^10, v=2^10, l=2^6 | 2^-54 | 2^-94 | | ||||
+-----------------------+----------------+----------------+ | ||||
v <= 112 | Figure 2: Probabilities for AEAD_AES_128_CCM_8 based on chosen q, | |||
v and l values. | ||||
3. Additional Information in the Security Context | 2.2. Additional Information in the Security Context | |||
In addition to what defined in Section 3.1 of [RFC8613], the OSCORE | In addition to what defined in Section 3.1 of [RFC8613], the OSCORE | |||
Security Context MUST also include the following information. | Security Context MUST also include the following information. | |||
2.2.1. Common Context | ||||
The Common Context is extended to include the following parameter. | ||||
* 'exp': with value the expiration time of the OSCORE Security | ||||
Context, as a non-negative integer. The parameter contains a | ||||
numeric value representing the number of seconds from | ||||
1970-01-01T00:00:00Z UTC until the specified UTC date/time, | ||||
ignoring leap seconds, analogous to what specified for NumericDate | ||||
in Section 2 of [RFC7519]. | ||||
At the time indicated in this field, a peer MUST stop using this | ||||
Security Context to process any incoming or outgoing message, and | ||||
is required to establish a new Security Context to continue | ||||
OSCORE-protected communications with the other peer. | ||||
2.2.2. Sender Context | ||||
The Sender Context is extended to include the following parameters. | The Sender Context is extended to include the following parameters. | |||
o 'count_q': a non-negative integer counter, keeping track of the | * 'count_q': a non-negative integer counter, keeping track of the | |||
current 'q' value for the Sender Key. At any time, 'count_q' has | current 'q' value for the Sender Key. At any time, 'count_q' has | |||
as value the number of messages that have been encrypted using the | as value the number of messages that have been encrypted using the | |||
Sender Key. The value of 'count_q' is set to 0 when establishing | Sender Key. The value of 'count_q' is set to 0 when establishing | |||
the Sender Context. | the Sender Context. | |||
o 'limit_q': a non-negative integer, which specifies the highest | * 'limit_q': a non-negative integer, which specifies the highest | |||
value that 'count_q' is allowed to reach, before stopping using | value that 'count_q' is allowed to reach, before stopping using | |||
the Sender Key to process outgoing messages. | the Sender Key to process outgoing messages. | |||
The value of 'limit_q' depends on the AEAD algorithm specified in | The value of 'limit_q' depends on the AEAD algorithm specified in | |||
the Common Context, considering the properties of that algorithm. | the Common Context, considering the properties of that algorithm. | |||
The value of 'limit_q' is determined according to Section 3. | The value of 'limit_q' is determined according to Section 2.1.1. | |||
2.2.3. Recipient Context | ||||
The Recipient Context is extended to include the following | The Recipient Context is extended to include the following | |||
parameters. | parameters. | |||
o 'count_v': a non-negative integer counter, keeping track of the | * 'count_v': a non-negative integer counter, keeping track of the | |||
current 'v' value for the Recipient Key. At any time, 'count_v' | current 'v' value for the Recipient Key. At any time, 'count_v' | |||
has as value the number of failed decryptions occurred on incoming | has as value the number of failed decryptions occurred on incoming | |||
messages using the Recipient Key. The value of 'count_v' is set to | messages using the Recipient Key. The value of 'count_v' is set to | |||
0 when establishing the Recipient Context. | 0 when establishing the Recipient Context. | |||
o 'limit_v': a non-negative integer, which specifies the highest | * 'limit_v': a non-negative integer, which specifies the highest | |||
value that 'count_v' is allowed to reach, before stopping using | value that 'count_v' is allowed to reach, before stopping using | |||
the Recipient Key to process incoming messages. | the Recipient Key to process incoming messages. | |||
The value of 'limit_v' depends on the AEAD algorithm specified in | The value of 'limit_v' depends on the AEAD algorithm specified in | |||
the Common Context, considering the properties of that algorithm. | the Common Context, considering the properties of that algorithm. | |||
The value of 'limit_v' is determined according to Section 3. | The value of 'limit_v' is determined according to Section 2.1.1. | |||
4. OSCORE Messages Processing | 2.3. OSCORE Messages Processing | |||
In order to keep track of the 'q' and 'v' values and ensure that AEAD | In order to keep track of the 'q' and 'v' values and ensure that AEAD | |||
keys are not used beyond reaching their limits, the processing of | keys are not used beyond reaching their limits, the processing of | |||
OSCORE messages is extended as defined in this section. | OSCORE messages is extended as defined in this section. | |||
In particular, the processing of OSCORE messages follows the steps | In particular, the processing of OSCORE messages follows the steps | |||
outlined in Section 8 of [RFC8613], with the additions defined below. | outlined in Section 8 of [RFC8613], with the additions defined below. | |||
4.1. Protecting a Request or a Response | 2.3.1. Protecting a Request or a Response | |||
Before encrypting the COSE object using the Sender Key, the 'count_q' | Before encrypting the COSE object using the Sender Key, the 'count_q' | |||
counter MUST be incremented. | counter MUST be incremented. | |||
If 'count_q' exceeds the 'limit_q' limit, the message processing MUST | If 'count_q' exceeds the 'limit_q' limit, the message processing MUST | |||
be aborted. From then on, the Sender Key MUST NOT be used to encrypt | be aborted. From then on, the Sender Key MUST NOT be used to encrypt | |||
further messages. | further messages. | |||
4.2. Verifying a Request or a Response | 2.3.2. Verifying a Request or a Response | |||
If an incoming message is detected to be a replay (see Section 7.4 of | ||||
[RFC8613]), the 'count_v' counter MUST NOT be incremented. | ||||
If the decryption and verification of the COSE object using the | If the decryption and verification of the COSE object using the | |||
Recipient Key fails, the 'count_v' counter MUST be incremented. | Recipient Key fails, the 'count_v' counter MUST be incremented. | |||
After 'count_v' has exceeded the 'limit_v' limit, incoming messages | After 'count_v' has exceeded the 'limit_v' limit, incoming messages | |||
MUST NOT be decrypted and verified using the Recipient Key, and their | MUST NOT be decrypted and verified using the Recipient Key, and their | |||
processing MUST be aborted. | processing MUST be aborted. | |||
5. Methods for Rekeying OSCORE | 2.4. Current methods for Rekeying OSCORE | |||
Before the limit of 'q' or 'v' has been reached for an OSCORE | Before the limit of 'q' or 'v' has been reached for an OSCORE | |||
Security Context, the two peers have to establish a new OSCORE | Security Context, the two peers have to establish a new OSCORE | |||
Security Context, in order to continue using OSCORE for secure | Security Context, in order to continue using OSCORE for secure | |||
communication. | communication. | |||
In practice, the two peers have to establish new Sender and Recipient | In practice, the two peers have to establish new Sender and Recipient | |||
Keys, as the keys actually used by the AEAD algorithm. When this | Keys, as the keys actually used by the AEAD algorithm. When this | |||
happens, both peers reset their 'count_q' and 'count_v' values to 0 | happens, both peers reset their 'count_q' and 'count_v' values to 0 | |||
(see Section 3). | (see Section 2.2). | |||
Currently, a number of ways exist to accomplish this. | Other specifications define a number of ways to accomplish this. | |||
o The two peers can run the procedure defined in Appendix B.2 of | * The two peers can run the procedure defined in Appendix B.2 of | |||
[RFC8613]. That is, the two peers exchange three or four | [RFC8613]. That is, the two peers exchange three or four | |||
messages, protected with temporary Security Contexts adding | messages, protected with temporary Security Contexts adding | |||
randomness to the ID Context. | randomness to the ID Context. | |||
As a result, the two peers establish a new OSCORE Security Context | As a result, the two peers establish a new OSCORE Security Context | |||
with new ID Context, Sender Key and Recipient Key, while keeping | with new ID Context, Sender Key and Recipient Key, while keeping | |||
the same OSCORE Master Secret and OSCORE Master Salt from the old | the same OSCORE Master Secret and OSCORE Master Salt from the old | |||
OSCORE Security Context. | OSCORE Security Context. | |||
This procedure does not require any additional components to what | This procedure does not require any additional components to what | |||
OSCORE already provides, and it does not provide perfect forward | OSCORE already provides, and it does not provide perfect forward | |||
secrecy. | secrecy. | |||
o The two peers can run the OSCORE profile | * The two peers can run the OSCORE profile | |||
[I-D.ietf-ace-oscore-profile] of the Authentication and | [I-D.ietf-ace-oscore-profile] of the Authentication and | |||
Authorization for Constrained Environments (ACE) Framework | Authorization for Constrained Environments (ACE) Framework | |||
[I-D.ietf-ace-oauth-authz]. | [I-D.ietf-ace-oauth-authz]. | |||
When a CoAP client uploads an Access Token to a CoAP server as an | When a CoAP client uploads an Access Token to a CoAP server as an | |||
access credential, the two peers also exchange two nonces. Then, | access credential, the two peers also exchange two nonces. Then, | |||
the two peers use the two nonces together with information | the two peers use the two nonces together with information | |||
provided by the ACE Authorization Server that issued the Access | provided by the ACE Authorization Server that issued the Access | |||
Token, in order to derive an OSCORE Security Context. | Token, in order to derive an OSCORE Security Context. | |||
This procedure does not provide perfect forward secrecy. | This procedure does not provide perfect forward secrecy. | |||
o The two peers can run the EDHOC key exchange protocol based on | * The two peers can run the EDHOC key exchange protocol based on | |||
Diffie-Hellman and defined in [I-D.ietf-lake-edhoc], in order to | Diffie-Hellman and defined in [I-D.ietf-lake-edhoc], in order to | |||
establish a pseudo-random key in a mutually authenticated way. | establish a pseudo-random key in a mutually authenticated way. | |||
Then, the two peers can use the established pseudo-random key to | Then, the two peers can use the established pseudo-random key to | |||
derive external application keys. This allows the two peers to | derive external application keys. This allows the two peers to | |||
securely derive especially an OSCORE Master Secret and an OSCORE | securely derive especially an OSCORE Master Secret and an OSCORE | |||
Master Salt, from which an OSCORE Security Context can be | Master Salt, from which an OSCORE Security Context can be | |||
established. | established. | |||
This procedure additionally provides perfect forward secrecy. | This procedure additionally provides perfect forward secrecy. | |||
* If one peer is acting as LwM2M Client and the other peer as LwM2M | ||||
Server, according to the OMA Lightweight Machine to Machine Core | ||||
specification [LwM2M], then the LwM2M Client peer may take the | ||||
initiative to bootstrap again with the LwM2M Bootstrap Server, and | ||||
receive again an OSCORE Security Context. Alternatively, the | ||||
LwM2M Server can instruct the LwM2M Client to initiate this | ||||
procedure. | ||||
If the OSCORE Security Context information on the LwM2M Bootstrap | ||||
Server has been updated, the LwM2M Client will thus receive a | ||||
fresh OSCORE Security Context to use with the LwM2M Server. | ||||
Manually updating the OSCORE Security Context at the two peers should | Manually updating the OSCORE Security Context at the two peers should | |||
be a last resort option, and it might often be not practical or | be a last resort option, and it might often be not practical or | |||
feasible. | feasible. | |||
Even when any of the alternatives mentioned above is available, it is | ||||
RECOMMENDED that two OSCORE peers update their Security Context by | ||||
using the procedure defined in Section 3 of this document. | ||||
It is RECOMMENDED that the peer initiating the rekeying procedure | It is RECOMMENDED that the peer initiating the rekeying procedure | |||
starts it before reaching the 'q' or 'v' limits. Otherwise, the AEAD | starts it before reaching the 'q' or 'v' limits. Otherwise, the AEAD | |||
keys possibly to be used during the rekeying procedure itself may | keys possibly to be used during the rekeying procedure itself may | |||
already be or become invalid before the rekeying is completed, which | already be or become invalid before the rekeying is completed, which | |||
may prevent a successful establishment of the new OSCORE Security | may prevent a successful establishment of the new OSCORE Security | |||
Context altogether. | Context altogether. | |||
6. Security Considerations | 3. New Method for Rekeying OSCORE | |||
This section defines a lightweight method that two OSCORE peers can | ||||
use to update their keying material and establish a new OSCORE | ||||
Security Context. | ||||
The key update procedure relies on the support function updateCtx() | ||||
defined in Section 3.2 and the message exchange defined in | ||||
Section 3.3. The following properties are fulfilled. | ||||
* The procedure can be initiated by either peer. In particular, the | ||||
client or the server may start the procedure by sending the first | ||||
rekeying message. | ||||
* The new OSCORE Security Context enjoys Perfect Forward Secrecy. | ||||
* The same ID Context value used in the old OSCORE Security Context | ||||
is preserved in the new Security Context. Furthermore, the ID | ||||
Context value never changes throughout the procedure. | ||||
* The procedure is robust against a peer rebooting, and it | ||||
especially avoids the reuse of AEAD (nonce, key) pairs. | ||||
* The procedure completes in one round trip. The two peers achieve | ||||
mutual proof-of-possession in the following exchange, which is | ||||
protected with the newly established OSCORE Security Context. | ||||
3.1. Extensions to the OSCORE Option | ||||
In order to support the message exchange for establishing a new | ||||
OSCORE Security Context as defined in Section 3.3, this document | ||||
extends the use of the OSCORE option originally defined in [RFC8613] | ||||
as follows. | ||||
* This document defines the usage of the seventh least significant | ||||
bit, called "Extension-1 Flag", in the first byte of the OSCORE | ||||
option containing the OSCORE flag bits. This flag bit is | ||||
specified in Section 5.1. | ||||
When the Extension-1 Flag is set to 1, the second byte of the | ||||
OSCORE option MUST include the set of OSCORE flag bits 8-15. | ||||
* This document defines the usage of the first least significant bit | ||||
"ID Detail Flag", 'd', in the second byte of the OSCORE option | ||||
containing the OSCORE flag bits. This flag bit is specified in | ||||
Section 5.1. | ||||
When it is set to 1, the compressed COSE object contains an 'id | ||||
detail', to be used for the key update procedure defined in | ||||
Section 3.3. In particular, the 1 byte following 'kid context' | ||||
(if any) encodes the length x of 'id detail', and the following x | ||||
bytes encode 'id detail'. | ||||
* The second-to-eighth least significant bits in the second byte of | ||||
the OSCORE option containing the OSCORE flag bits are reserved for | ||||
future use. These bits SHALL be set to zero when not in use. | ||||
According to this specification, if any of these bits are set to | ||||
1, the message is considered to be malformed and decompression | ||||
fails as specified in item 2 of Section 8.2 of [RFC8613]. | ||||
Figure 3 shows the OSCORE option value including also 'id detail'. | ||||
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <----- n bytes -----> | ||||
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ | ||||
|0|1|0|h|k| n | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) | | ||||
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ | ||||
<- 1 byte -> <----- s bytes ------> <- 1 byte -> <----- x bytes ----> | ||||
+------------+----------------------+---------------------------------+ | ||||
| s (if any) | kid context (if any) | x (if any) | id detail (if any) | | ||||
+------------+----------------------+------------+--------------------+ | ||||
+------------------+ | ||||
| kid (if any) ... | | ||||
+------------------+ | ||||
Figure 3: The OSCORE option value, including 'id detail' | ||||
3.2. Update Function | ||||
The updateCtx() function shown in Figure 4 takes as input a nonce N | ||||
as well as an OSCORE Security Context CTX_IN, and returns a new | ||||
OSCORE Security Context CTX_OUT. | ||||
First, the updateCtx() function derives the new values of the Master | ||||
Secret and Master Salt for CTX_OUT as follows. | ||||
* If the two peers established their original Security Context as a | ||||
result of running the EDHOC protocol [I-D.ietf-lake-edhoc], the | ||||
EDHOC key PRK_4x3m is updated using the EDHOC-KeyUpdate() | ||||
function, which takes N as input. Then, the EDHOC-Exporter() | ||||
function is used to derive the new values for the Master Secret | ||||
and Master Salt. The original Security Context is the Security | ||||
Context a peer had before the key update procedure was used for | ||||
the first time. | ||||
* If the two peers established their original Security Context | ||||
through other means, the new Master Secret is derived through an | ||||
HKDF-Expand() step, which takes as input N as well as the Master | ||||
Secret value from the Security Context CTX_IN. Instead, the new | ||||
Master Salt takes N as value. | ||||
In either case, the derivation of new values follows the same | ||||
approach used in TLS 1.3, which is also based on HKDF-Expand (see | ||||
Section 7.1 of [RFC8446]) and used for computing new keying material | ||||
in case of key update (see Section 4.6.3 of [RFC8446]). | ||||
After that, the new Master Secret and Master Salt parameters are used | ||||
to derive a new Security Context CTX_OUT as per Section 3.2 of | ||||
[RFC8613]. Any other parameter required for the derivation takes the | ||||
same value as in the Security Context CTX_IN. Finally, the function | ||||
returns the newly derived Security Context CTX_OUT. | ||||
updateCtx( N, CTX_IN ) { | ||||
CTX_OUT // The new Security Context | ||||
MSECRET_NEW // The new Master Secret | ||||
MSALT_NEW // The new Master Salt | ||||
if <the original Security Context was established through EDHOC> { | ||||
EDHOC-KeyUpdate( N ) | ||||
// This results in updating the key PRK_4x3m of the EDHOC session, | ||||
// i.e., PRK_4x3m = Extract( N, PRK_4x3m ) | ||||
MSECRET_NEW = EDHOC-Exporter( "OSCORE Master Secret", key_length ) | ||||
= EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", key_length ) | ||||
MSALT_NEW = EDHOC-Exporter( "OSCORE Master Salt", salt_length ) | ||||
= EDHOC-KDF( PRK_4x3m, TH_4, "OSCORE Master Salt", salt_length ) | ||||
} | ||||
else { | ||||
Master Secret Length = < Size of CTX_IN.MasterSecret in bytes > | ||||
MSECRET_NEW = HKDF-Expand-Label(CTX_IN.MasterSecret, Label, | ||||
N, Master Secret Length) | ||||
= HKDF-Expand(CTX_IN.MasterSecret, HkdfLabel, | ||||
Master Secret Length) | ||||
MSALT_NEW = N; | ||||
} | ||||
< Derive CTX_OUT using MSECRET_NEW and MSALT_NEW, | ||||
together with other parameters from CTX_IN > | ||||
Return CTX_OUT; | ||||
} | ||||
Where HkdfLabel is defined as | ||||
struct { | ||||
uint16 length = Length; | ||||
opaque label<7..255> = "oscore " + Label; | ||||
opaque context<0..255> = Context; | ||||
} HkdfLabel; | ||||
Figure 4: Function for deriving a new OSCORE Security Context | ||||
3.3. Establishment of the New OSCORE Security Context | ||||
This section defines the actual message exchange performed by two | ||||
peers to update their OSCORE keying material. Before starting the | ||||
key update procedure, the two peers share the OSCORE Security Context | ||||
CTX_OLD. Once completed the key update procedure, the two peers | ||||
agree on a newly established OSCORE Security Context CTX_NEW. | ||||
In particular, each peer contributes by generating a fresh value R1 | ||||
or R2, and providing it to the other peer. Their concatenation R1|R2 | ||||
is used as input N by the updateCtx() function, in order to derive | ||||
the new OSCORE Security Context CTX_NEW. | ||||
Both in the client- and server-initiated version of the procedure: | ||||
* The initiator always offers the fresh value R1. | ||||
* The responder always offers the fresh value R2. | ||||
* The responder is always the first one deriving the new OSCORE | ||||
Security Context CTX_NEW. | ||||
* The initiator is always the first one achieving key confirmation, | ||||
hence able to safely discard the old OSCORE Security Context | ||||
CTX_OLD. | ||||
* Both the initiator and the responder use the same respective | ||||
OSCORE Sender ID and Recipient ID. Also, they both preserve and | ||||
use the same OSCORE ID Context from CTX_OLD. | ||||
Figure 5 shows the key update procedure with the client acting as | ||||
initiator. | ||||
Client Server | ||||
(initiator) (responder) | ||||
| | | ||||
Generate R1 | | | ||||
| | | ||||
CTX_1 = | | | ||||
updateCtx(R1, | | | ||||
CTX_OLD) | | | ||||
| | | ||||
| Request #1 | | ||||
Protect with CTX_1 |------------------->| | ||||
| OSCORE Option: | CTX_1 = | ||||
| ... | update(R1, | ||||
| d flag: 1 | CTX_OLD) | ||||
| ... | | ||||
| ID Detail: R1 | Verify with CTX_1 | ||||
| ... | | ||||
| | Generate R2 | ||||
| | | ||||
| | CTX_NEW = | ||||
| | update(R1|R2, | ||||
| | CTX_OLD) | ||||
| | | ||||
| Response #1 | | ||||
|<-------------------| Protect with CTX_NEW | ||||
CTX_NEW = | OSCORE Option: | | ||||
updateCtx(R1|R2, | ... | | ||||
CTX_OLD) | d flag: 1 | | ||||
| ... | | ||||
Verify with CTX_NEW | ID Detail: R1|R2 | | ||||
| ... | | ||||
Discard CTX_OLD | | | ||||
| | | ||||
// The actual key update ends here | ||||
// The two peers can use the new Security Context CTX_NEW | ||||
| | | ||||
| Request #2 | | ||||
Protect with CTX_NEW |------------------->| | ||||
| | Verify with CTX_NEW | ||||
| | | ||||
| | Discard CTX_OLD | ||||
| | | ||||
| Response #2 | | ||||
|<-------------------| Protect with CTX_NEW | ||||
Verify with CTX_NEW | | | ||||
| | | ||||
Figure 5: Procedure for Establishing a New Security Context | ||||
(Client-initiated) | ||||
First, the client generates a random value R1 and uses it together | ||||
with the old Security Context CTX_OLD to derive a temporary Security | ||||
Context CTX_1. Then, the client sends a request to the server, | ||||
protected with the Security Context CTX_1. In particular, the | ||||
request has the 'd' flag bit set to 1 and specifies R1 as 'id detail' | ||||
(see Section 3.1). | ||||
Upon receiving the request, the server derives the temporary Security | ||||
Context CTX_1, by using the value R1 retrieved from the request and | ||||
the old Security Context CTX_OLD. Then, the server verifies the | ||||
request by using the Security Context CTX_1. | ||||
After that, the server generates a random value R2 and uses the | ||||
concatenation R1|R2 together with the old Security Context CTX_OLD to | ||||
derive the new Security Context CTX_NEW. Then, the server, sends a | ||||
response to the client, protected with the new Security Context | ||||
CTX_NEW. In particular, the response has the 'd' flag bit set to 1 | ||||
and specifies R1|R2 as 'id detail'. | ||||
Upon receiving the response, the client retrieves the value R1|R2 | ||||
from the response, and verifies that R1 coincides with the value R1 | ||||
specified in the previously sent request. If so, the client derives | ||||
the new Security Context CTX_NEW, by using the value R1|R2 retrieved | ||||
from the response and the old Security Context CTX_OLD. Finally, the | ||||
client verifies the response by using the Security Context CTX_NEW | ||||
and deletes the old Security Context CTX_OLD. | ||||
After that, the client can send a new request protected with the new | ||||
Security Context CTX_NEW. When successfully verifying the request | ||||
using the Security Context CTX_NEW, the server deletes the old | ||||
Security Context CTX_OLD and can reply with a response protected with | ||||
the new Security Context CTX_NEW. | ||||
From then on, the two peers can protect their message exchanges by | ||||
using the new Security Context CTX_NEW. | ||||
Figure 6 shows the key update procedure with the server acting as | ||||
initiator. | ||||
Client Server | ||||
(responder) (initiator) | ||||
| | | ||||
| Request #1 | | ||||
Protect with CTX_OLD |------------------->| | ||||
| | Verify with CTX_OLD | ||||
| | | ||||
| | Generate R1 | ||||
| | | ||||
| | CTX_1 = | ||||
| | updateCtx(R1, | ||||
| | CTX_OLD) | ||||
| | | ||||
| Response #1 | | ||||
|<-------------------| Protect with CTX_1 | ||||
CTX_1 = | OSCORE Option: | | ||||
updateCtx(R1, | ... | | ||||
CTX_OLD) | d flag: 1 | | ||||
| ... | | ||||
Verify with CTX_1 | ID Detail: R1 | | ||||
| ... | | ||||
Generate R2 | | | ||||
| | | ||||
CTX_NEW = | | | ||||
updateCtx(R1|R2, | | | ||||
CTX_OLD) | | | ||||
| | | ||||
| Request #2 | | ||||
Protect with CTX_NEW |------------------->| | ||||
| OSCORE Option: | CTX_NEW = | ||||
| ... | updateCtx(R1|R2, | ||||
| d flag: 1 | CTX_OLD) | ||||
| ... | | ||||
| ID Detail: R1|R2 | Verify with CTX_NEW | ||||
| ... | | ||||
| | Discard CTX_OLD | ||||
| | | ||||
// The actual key update ends here | ||||
// The two peers can use the new Security Context CTX_NEW | ||||
| Response #2 | | ||||
|<-------------------| Protect with CTX_NEW | ||||
Verify with CTX_NEW | | | ||||
| | | ||||
Discard CTX_OLD | | | ||||
| | | ||||
Figure 6: Procedure for Establishing a New Security Context | ||||
(Server-initiated) | ||||
First, the client sends a normal request to the server, protected | ||||
with the old Security Context CTX_OLD. | ||||
Upon receiving the request and after having verified it with the old | ||||
Security Context CTX_OLD as usual, the server generates a random | ||||
value R1 and uses it together with the old Security Context CTX_OLD | ||||
to derive a temporary Security Context CTX_1. Then, the server sends | ||||
a response to the client, protected with the Security Context CTX_1. | ||||
In particular, the request has the 'd' flag bit set to 1 and | ||||
specifies R1 as 'id detail' (see Section 3.1). | ||||
Upon receiving the response, the client derives the temporary | ||||
Security Context CTX_1, by using the value R1 retrieved from the | ||||
response and the old Security Context CTX_OLD. Then, the client | ||||
verifies the response by using the Security Context CTX_1. | ||||
After that, the client generates a random value R2 and uses the | ||||
concatenation R1|R2 together with the old Security Context CTX_OLD to | ||||
derive the new Security Context CTX_NEW. Then, the client, sends a | ||||
request to the server, protected with the new Security Context | ||||
CTX_NEW. In particular, the request has the 'd' flag bit set to 1 | ||||
and specifies R1|R2 as 'id detail'. | ||||
Upon receiving the request, the server retrieves the value R1|R2 from | ||||
the request, and verifies that R1 coincides with the value R1 | ||||
specified in the previously sent response. If so, the server derives | ||||
the new Security Context CTX_NEW, by using the value R1|R2 retrieved | ||||
from the request and the old Security Context CTX_OLD. Finally, the | ||||
server verifies the request by using the Security Context CTX_NEW and | ||||
deletes the old Security Context CTX_OLD. | ||||
After that, the client can send a response protected with the new | ||||
Security Context CTX_NEW. When successfully verifying the response | ||||
using the Security Context CTX_NEW, the client deletes the old | ||||
Security Context CTX_OLD. | ||||
From then on, the two peers can protect their message exchanges by | ||||
using the new Security Context CTX_NEW. | ||||
3.4. Retention Policies | ||||
Applications MAY define policies that allows a peer to also | ||||
temporarily keep the old Security Context CTX_OLD, rather than simply | ||||
overwriting it to become CTX_NEW. This allows the peer to decrypt | ||||
late, still on-the-fly incoming messages protected with CTX_OLD. | ||||
When enforcing such policies, the following applies. | ||||
* Outgoing messages MUST be protected by using only CTX_NEW. | ||||
* Incoming messages MUST first be attempted to decrypt by using | ||||
CTX_NEW. If decryption fails, a second attempt can use CTX_OLD. | ||||
* When an amount of time defined by the policy has elapsed since the | ||||
establishment of CTX_NEW, the peer deletes CTX_OLD. | ||||
4. Security Considerations | ||||
This document mainly covers security considerations about using AEAD | This document mainly covers security considerations about using AEAD | |||
keys in OSCORE and their usage limits, in addition to the security | keys in OSCORE and their usage limits, in addition to the security | |||
considerations of [RFC8613]. | considerations of [RFC8613]. | |||
Depending on the specific rekeying procedure used to establish a new | Depending on the specific rekeying procedure used to establish a new | |||
OSCORE Security Context, the related security considerations also | OSCORE Security Context, the related security considerations also | |||
apply. | apply. | |||
TODO: Add more considerations. | TODO: Add more considerations. | |||
7. IANA Considerations | 5. IANA Considerations | |||
This document has no actions for IANA. | This document has the following actions for IANA. | |||
Acknowledgments | 5.1. OSCORE Flag Bits Registry | |||
The authors sincerely thank Christian Amsuess, John Mattsson and | IANA is asked to add the following value entries to the "OSCORE Flag | |||
Goeran Selander for the initial discussions that allowed shaping this | Bits" subregistry as part of the "CoRE Parameters" registry. | |||
document. | ||||
The work on this document has been partly supported by VINNOVA and | +----------+------------------+------------------------+-----------+ | |||
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home | | Bit | Name | Description | Reference | | |||
(Grant agreement 952652). | | Position | | | | | |||
+----------+------------------+------------------------+-----------+ | ||||
| 1 | Extension-1 Flag | Set to 1 if the OSCORE | [This | | ||||
| | | Option specifies a | Document] | | ||||
| | | second byte of OSCORE | | | ||||
| | | flag bits | | | ||||
+----------+------------------+------------------------+-----------+ | ||||
| 15 | ID Detail Flag | Set to 1 if the | [This | | ||||
| | | compressed COSE object | Document] | | ||||
| | | contains 'id detail' | | | ||||
+----------+------------------+------------------------+-----------+ | ||||
9. References | 6. References | |||
9.1. Normative References | 6.1. Normative References | |||
[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/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
[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/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | |||
"Object Security for Constrained RESTful Environments | "Object Security for Constrained RESTful Environments | |||
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | |||
<https://www.rfc-editor.org/info/rfc8613>. | <https://www.rfc-editor.org/info/rfc8613>. | |||
9.2. Informative References | 6.2. Informative References | |||
[I-D.ietf-ace-oauth-authz] | [I-D.ietf-ace-oauth-authz] | |||
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and | Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and | |||
H. Tschofenig, "Authentication and Authorization for | H. Tschofenig, "Authentication and Authorization for | |||
Constrained Environments (ACE) using the OAuth 2.0 | Constrained Environments (ACE) using the OAuth 2.0 | |||
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 | Framework (ACE-OAuth)", Work in Progress, Internet-Draft, | |||
(work in progress), November 2020. | draft-ietf-ace-oauth-authz-43, 10 July 2021, | |||
<https://www.ietf.org/archive/id/draft-ietf-ace-oauth- | ||||
authz-43.txt>. | ||||
[I-D.ietf-ace-oscore-profile] | [I-D.ietf-ace-oscore-profile] | |||
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, | Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, | |||
"OSCORE Profile of the Authentication and Authorization | "OSCORE Profile of the Authentication and Authorization | |||
for Constrained Environments Framework", draft-ietf-ace- | for Constrained Environments Framework", Work in Progress, | |||
oscore-profile-15 (work in progress), January 2021. | Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May | |||
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- | ||||
oscore-profile-19.txt>. | ||||
[I-D.ietf-lake-edhoc] | [I-D.ietf-lake-edhoc] | |||
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral | Selander, G., Mattsson, J. P., and F. Palombini, | |||
Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- | "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in | |||
edhoc-03 (work in progress), December 2020. | Progress, Internet-Draft, draft-ietf-lake-edhoc-07, 24 May | |||
2021, <https://www.ietf.org/archive/id/draft-ietf-lake- | ||||
[I-D.ietf-tls-dtls13] | edhoc-07.txt>. | |||
Rescorla, E., Tschofenig, H., and N. Modadugu, "The | ||||
Datagram Transport Layer Security (DTLS) Protocol Version | ||||
1.3", draft-ietf-tls-dtls13-40 (work in progress), January | ||||
2021. | ||||
[I-D.irtf-cfrg-aead-limits] | [I-D.irtf-cfrg-aead-limits] | |||
Guenther, F., Thomson, M., and C. Wood, "Usage Limits on | Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on | |||
AEAD Algorithms", draft-irtf-cfrg-aead-limits-01 (work in | AEAD Algorithms", Work in Progress, Internet-Draft, draft- | |||
progress), September 2020. | irtf-cfrg-aead-limits-02, 22 February 2021, | |||
<https://www.ietf.org/archive/id/draft-irtf-cfrg-aead- | ||||
limits-02.txt>. | ||||
[LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine | ||||
Technical Specification - Core, Approved Version 1.2, OMA- | ||||
TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, | ||||
<http://www.openmobilealliance.org/release/LightweightM2M/ | ||||
V1_2-20201110-A/OMA-TS-LightweightM2M_Core- | ||||
V1_2-20201110-A.pdf>. | ||||
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | ||||
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | ||||
<https://www.rfc-editor.org/info/rfc7519>. | ||||
[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>. | ||||
Acknowledgments | ||||
The authors sincerely thank Christian Amsuess, John Mattsson and | ||||
Goeran Selander for the initial discussions that allowed shaping this | ||||
document. | ||||
The work on this document has been partly supported by VINNOVA and | ||||
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home | ||||
(Grant agreement 952652). | ||||
Authors' Addresses | Authors' Addresses | |||
Rikard Hoeglund | Rikard Höglund | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
Kista SE-16440 Stockholm | SE-16440 Stockholm Kista | |||
Sweden | Sweden | |||
Email: rikard.hoglund@ri.se | Email: rikard.hoglund@ri.se | |||
Marco Tiloca | Marco Tiloca | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
Kista SE-16440 Stockholm | SE-16440 Stockholm Kista | |||
Sweden | Sweden | |||
Email: marco.tiloca@ri.se | Email: marco.tiloca@ri.se | |||
End of changes. 59 change blocks. | ||||
99 lines changed or deleted | 643 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |