draft-ietf-ace-oscore-profile-16.txt   draft-ietf-ace-oscore-profile-17.txt 
ACE Working Group F. Palombini ACE Working Group F. Palombini
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track L. Seitz Intended status: Standards Track L. Seitz
Expires: August 1, 2021 Combitech Expires: September 9, 2021 Combitech
G. Selander G. Selander
Ericsson AB Ericsson AB
M. Gunnarsson M. Gunnarsson
RISE RISE
January 28, 2021 March 8, 2021
OSCORE Profile of the Authentication and Authorization for Constrained OSCORE Profile of the Authentication and Authorization for Constrained
Environments Framework Environments Framework
draft-ietf-ace-oscore-profile-16 draft-ietf-ace-oscore-profile-17
Abstract Abstract
This memo specifies a profile for the Authentication and This memo specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. It Authorization for Constrained Environments (ACE) framework. It
utilizes Object Security for Constrained RESTful Environments utilizes Object Security for Constrained RESTful Environments
(OSCORE) to provide communication security and proof-of-possession (OSCORE) to provide communication security and proof-of-possession
for a key owned by the client and bound to an OAuth 2.0 access token. for a key owned by the client and bound to an OAuth 2.0 access token.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 1, 2021. This Internet-Draft will expire on September 9, 2021.
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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 51 skipping to change at page 3, line 51
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
defined in OSCORE [RFC8613], such as "Security Context" and defined in OSCORE [RFC8613], such as "Security Context" and
"Recipient ID". "Recipient ID".
Terminology for entities in the architecture is defined in OAuth 2.0 Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749], such as client (C), resource server (RS), and [RFC6749], such as client (C), resource server (RS), and
authorization server (AS). It is assumed in this document that a authorization server (AS). It is assumed in this document that a
given resource on a specific RS is associated to a unique AS. given resource on a specific RS is associated to a unique AS.
Concise Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis] Concise Binary Object Representation (CBOR) [RFC8949] and Concise
and Concise Data Definition Language (CDDL) [RFC8610] are used in Data Definition Language (CDDL) [RFC8610] are used in this
this specification. CDDL predefined type names, especially bstr for specification. CDDL predefined type names, especially bstr for CBOR
CBOR byte strings and tstr for CBOR text strings, are used byte strings and tstr for CBOR text strings, are used extensively in
extensively in the document. the document.
Note that the term "endpoint" is used here, as in Note that the term "endpoint" is used here, as in
[I-D.ietf-ace-oauth-authz], following its OAuth definition, which is [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is
to denote resources such as token and introspect at the AS and authz- to denote resources such as token and introspect at the AS and authz-
info at the RS. The CoAP [RFC7252] definition, which is "An entity info at the RS. The CoAP [RFC7252] definition, which is "An entity
participating in the CoAP protocol" is not used in this memo. participating in the CoAP protocol" is not used in this memo.
2. Protocol Overview 2. Protocol Overview
This section gives an overview of how to use the ACE Framework This section gives an overview of how to use the ACE Framework
skipping to change at page 5, line 31 skipping to change at page 5, line 31
Finally, the client starts the communication with the RS by sending a Finally, the client starts the communication with the RS by sending a
request protected with OSCORE to the RS. If the request is request protected with OSCORE to the RS. If the request is
successfully verified, the server stores the complete Security successfully verified, the server stores the complete Security
Context state that is ready for use in protecting messages, and uses Context state that is ready for use in protecting messages, and uses
it in the response, and in further communications with the client, it in the response, and in further communications with the client,
until token deletion, due to e.g. expiration. This Security Context until token deletion, due to e.g. expiration. This Security Context
is discarded when a token (whether the same or a different one) is is discarded when a token (whether the same or a different one) is
used to successfully derive a new Security Context for that client. used to successfully derive a new Security Context for that client.
The use of nonces during the exchange prevents the reuse of an The use of nonces N1 and N2 during the exchange prevents the reuse of
Authenticated Encryption with Associated Data (AEAD) nonces/key pair an Authenticated Encryption with Associated Data (AEAD) nonce/key
for two different messages. Reuse might otherwise occur when client pair for two different messages. Reuse might otherwise occur when
and RS derive a new Security Context from an existing (non- expired) client and RS derive a new Security Context from an existing (non-
access token, as might occur when either party has just rebooted, and expired) access token, as might occur when either party has just
might lead to loss of both confidentiality and integrity. Instead, rebooted, and might lead to loss of both confidentiality and
by using nonces as part of the Master Salt, the request to the authz- integrity. Instead, by using the exchanged nonces N1 and N2 as part
info endpoint posting the same token results in a different Security of the Master Salt, the request to the authz-info endpoint posting
Context, by OSCORE construction, since even though the Master Secret, the same token results in a different Security Context, by OSCORE
Sender ID and Recipient ID are the same, the Master Salt is different construction, since even though the Master Secret, Sender ID and
(see Section 3.2.1 of [RFC8613]). If nonces were reused, a node Recipient ID are the same, the Master Salt is different (see
reusing a non-expired old token would be susceptible to on-path Section 3.2.1 of [RFC8613]). If the exchanged nonces were reused, a
attackers provoking the creation of OSCORE messages using old AEAD node reusing a non-expired old token would be susceptible to on-path
keys and nonces. attackers provoking the creation of an OSCORE message using an old
AEAD key and nonce.
After the whole message exchange has taken place, the client can After the whole message exchange has taken place, the client can
contact the AS to request an update of its access rights, sending a contact the AS to request an update of its access rights, sending a
similar request to the token endpoint that also includes an similar request to the token endpoint that also includes an
identifier so that the AS can find the correct OSCORE security input identifier so that the AS can find the correct OSCORE security input
material it has previously shared with the client. This specific material it has previously shared with the client. This specific
identifier, encoded as a byte string, is assigned by the AS to be identifier, encoded as a byte string, is assigned by the AS to be
unique in the sets of its OSCORE security input materials, and is not unique in the sets of its OSCORE security input materials, and is not
used as input material to derive the full OSCORE Security Context. used as input material to derive the full OSCORE Security Context.
skipping to change at page 6, line 39 skipping to change at page 6, line 40
| | | | | |
| <--- OSCORE Response ----- | | | <--- OSCORE Response ----- | |
| | | | | |
/proof-of-possession | | /proof-of-possession | |
Sec Context storage/ | | Sec Context storage/ | |
| | | | | |
| ---- OSCORE Request -----> | | | ---- OSCORE Request -----> | |
| | | | | |
| <--- OSCORE Response ----- | | | <--- OSCORE Response ----- | |
| | | | | |
/mutual ... | | | ... | |
authentication/
Figure 1: Protocol Overview Figure 1: Protocol Overview
3. Client-AS Communication 3. Client-AS Communication
The following subsections describe the details of the POST request The following subsections describe the details of the POST request
and response to the token endpoint between client and AS. and response to the token endpoint between client and AS.
Section 3.2 of [RFC8613] defines how to derive a Security Context Section 3.2 of [RFC8613] defines how to derive a Security Context
based on a shared master secret and a set of other parameters, based on a shared master secret and a set of other parameters,
established between client and server, which the client receives from established between client and server, which the client receives from
skipping to change at page 15, line 36 skipping to change at page 15, line 36
4. Client-RS Communication 4. Client-RS Communication
The following subsections describe the details of the POST request The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS. The and response to the authz-info endpoint between client and RS. The
client generates a nonce N1 and an identifier ID1 unique in the sets client generates a nonce N1 and an identifier ID1 unique in the sets
of its own Recipient IDs, and posts them together with the token that of its own Recipient IDs, and posts them together with the token that
includes the materials (e.g., OSCORE parameters) received from the AS includes the materials (e.g., OSCORE parameters) received from the AS
to the RS. The RS then generates a nonce N2 and an identifier ID2 to the RS. The RS then generates a nonce N2 and an identifier ID2
unique in the sets of its own Recipient IDs, and uses Section 3.2 of unique in the sets of its own Recipient IDs, and uses Section 3.2 of
[RFC8613] to derive a security context based on a shared master [RFC8613] to derive a security context based on a shared master
secret, the two nonces and the two identifiers, established between secret, the two exchanged nonces and the two identifiers, established
client and server. The nonces and identifiers are encoded as CBOR between client and server. The exchanged nonces and identifiers are
byte string if CBOR is used, and as Base64 string if JSON is used. encoded as CBOR byte string if CBOR is used, and as Base64 string if
This security context is used to protect all future communication JSON is used. This security context is used to protect all future
between client and RS using OSCORE, as long as the access token is communication between client and RS using OSCORE, as long as the
valid. access token is valid.
Note that the RS and client authenticates each other by generating Note that the RS and client authenticates each other by generating
the shared OSCORE Security Context using the pop-key as master the shared OSCORE Security Context using the pop-key as master
secret. An attacker posting a valid token to the RS will not be able secret. An attacker posting a valid token to the RS will not be able
to generate a valid OSCORE Security Context and thus not be able to to generate a valid OSCORE Security Context and thus not be able to
prove possession of the pop-key. Additionally, the mutual prove possession of the pop-key. Additionally, the mutual
authentication is only achieved after the client has successfully authentication is only achieved after the client has successfully
verified a response from the RS protected with the generated OSCORE verified a response from the RS protected with the generated OSCORE
Security Context. Security Context.
4.1. C-to-RS: POST to authz-info endpoint 4.1. C-to-RS: POST to authz-info endpoint
The client MUST generate a nonce value very unlikely to have been The client MUST generate a nonce value N1 very unlikely to have been
previously used with the same input keying material. This profile previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce's value. The RECOMMENDS to use a 64-bit long random number as nonce's value. The
client MUST store the nonce N1 as long as the response from the RS is client MUST store the nonce N1 as long as the response from the RS is
not received and the access token related to it is still valid (to not received and the access token related to it is still valid (to
the best of the client's knowledge). the best of the client's knowledge).
The client generates its own Recipient ID, ID1, for the OSCORE The client generates its own Recipient ID, ID1, for the OSCORE
Security Context that it is establishing with the RS. By generating Security Context that it is establishing with the RS. By generating
its own Recipient ID, the client makes sure that it does not collide its own Recipient ID, the client makes sure that it does not collide
with any of its Recipient IDs, nor with any other identifier ID1 if with any of its Recipient IDs, nor with any other identifier ID1 if
skipping to change at page 16, line 46 skipping to change at page 16, line 46
The communication with the authz-info endpoint does not have to be The communication with the authz-info endpoint does not have to be
protected, except for the update of access rights case described protected, except for the update of access rights case described
below. below.
Note that a client may be required to re-POST the access token in Note that a client may be required to re-POST the access token in
order to complete a request, since an RS may delete a stored access order to complete a request, since an RS may delete a stored access
token (and associated Security Context) at any time, for example due token (and associated Security Context) at any time, for example due
to all storage space being consumed. This situation is detected by to all storage space being consumed. This situation is detected by
the client when it receives an AS Request Creation Hints response. the client when it receives an AS Request Creation Hints response.
Reposting the same access token will result in deriving a new OSCORE Reposting the same access token will result in deriving a new OSCORE
Security Context to be used with the RS, as different nonces will be Security Context to be used with the RS, as different exchanged
used. nonces will be used.
The client may also chose to re-POST the access token in order to The client may also chose to re-POST the access token in order to
renew its OSCORE Security Context. In that case, the client and the renew its OSCORE Security Context. In that case, the client and the
RS will exchange newly generated nonces, re-negotiate identifiers, RS will exchange newly generated nonces, re-negotiate identifiers,
and derive new keying material. The client and RS might decide to and derive new keying material. The client and RS might decide to
keep the same identifiers or renew them during the re-negotiation. keep the same identifiers or renew them during the re-negotiation.
Figure 10 shows an example of the request sent from the client to the Figure 10 shows an example of the request sent from the client to the
RS, with payload in CBOR diagnostic notation without the tag and RS, with payload in CBOR diagnostic notation without the tag and
value abbreviations. The access token has been truncated for value abbreviations. The access token has been truncated for
skipping to change at page 20, line 28 skipping to change at page 20, line 28
nonce N2 from the 'nonce2' parameter in the CBOR map in the payload nonce N2 from the 'nonce2' parameter in the CBOR map in the payload
of the response. Then, the client MUST set the Master Salt of the of the response. Then, the client MUST set the Master Salt of the
Security Context created to communicate with the RS to the Security Context created to communicate with the RS to the
concatenation of salt, N1, and N2, in this order: Master Salt = concatenation of salt, N1, and N2, in this order: Master Salt =
salt | N1 | N2, where | denotes byte string concatenation, where salt salt | N1 | N2, where | denotes byte string concatenation, where salt
is the CBOR byte string received from the AS in Section 3.2, and is the CBOR byte string received from the AS in Section 3.2, and
where N1 and N2 are the two nonces encoded as CBOR byte strings. An where N1 and N2 are the two nonces encoded as CBOR byte strings. An
example of Master Salt construction using CBOR encoding is given in example of Master Salt construction using CBOR encoding is given in
Figure 12. Figure 12.
N1, N2 and input salt expressed in CBOR diagnostic notation: N1, N2 and input salt expressed in CBOR diagnostic notation:
nonce1 = h'018a278f7faab55a' nonce1 = h'018a278f7faab55a'
nonce2 = h'25a8991cd700ac01' nonce2 = h'25a8991cd700ac01'
input salt = h'f9af838368e353e78888e1426bd94e6f' input salt = h'f9af838368e353e78888e1426bd94e6f'
N1, N2 and input salt as CBOR encoded byte strings: N1, N2 and input salt as CBOR encoded byte strings:
nonce1 = 0x48018a278f7faab55a nonce1 = 0x48018a278f7faab55a
nonce2 = 0x4825a8991cd700ac01 nonce2 = 0x4825a8991cd700ac01
input salt = 0x50f9af838368e353e78888e1426bd94e6f input salt = 0x50f9af838368e353e78888e1426bd94e6f
Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f 48 018a278f7faab55a 48 25a8991cd700ac01 Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f
48 018a278f7faab55a 48 25a8991cd700ac01
Figure 12: Example of Master Salt construction using CBOR encoding Figure 12: Example of Master Salt construction using CBOR encoding
If JSON is used instead of CBOR, the Master Salt of the Security If JSON is used instead of CBOR, the Master Salt of the Security
Context is the Base64 encoding of the concatenation of the same Context is the Base64 encoding of the concatenation of the same
parameters, each of them prefixed by their size, encoded in 1 byte. parameters, each of them prefixed by their size, encoded in 1 byte.
When using JSON, the nonces and input salt have a maximum size of 255 When using JSON, the nonces and input salt have a maximum size of 255
bytes. An example of Master Salt construction using Base64 encoding bytes. An example of Master Salt construction using Base64 encoding
is given in Figure 13. is given in Figure 13.
N1, N2 and input salt values: N1, N2 and input salt values:
nonce1 = 0x018a278f7faab55a (8 bytes) nonce1 = 0x018a278f7faab55a (8 bytes)
nonce2 = 0x25a8991cd700ac01 (8 bytes) nonce2 = 0x25a8991cd700ac01 (8 bytes)
input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes) input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes)
Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f 08 018a278f7faab55a 08 25a8991cd700ac01 Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f
08 018a278f7faab55a 08 25a8991cd700ac01
Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE=' Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE='
Figure 13: Example of Master Salt construction using Base64 encoding Figure 13: Example of Master Salt construction using Base64 encoding
The client MUST set the Sender ID to the ace_server_recipientid The client MUST set the Sender ID to the ace_server_recipientid
received in Section 4.2, and the Recipient ID to the received in Section 4.2, and the Recipient ID to the
ace_client_recipientid sent in Section 4.1. The client MUST set the ace_client_recipientid sent in Section 4.1. The client MUST set the
Master Secret from the parameter received from the AS in Section 3.2. Master Secret from the parameter received from the AS in Section 3.2.
The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE
Version from the parameters received from the AS in Section 3.2, if Version from the parameters received from the AS in Section 3.2, if
present. In case an optional parameter is omitted, the default value present. In case an optional parameter is omitted, the default value
skipping to change at page 24, line 47 skipping to change at page 24, line 47
the OSCORE response from the RS pass verification. the OSCORE response from the RS pass verification.
OSCORE is designed to secure point-to-point communication, providing OSCORE is designed to secure point-to-point communication, providing
a secure binding between the request and the response(s). Thus the a secure binding between the request and the response(s). Thus the
basic OSCORE protocol is not intended for use in point-to-multipoint basic OSCORE protocol is not intended for use in point-to-multipoint
communication (e.g., multicast, publish-subscribe). Implementers of communication (e.g., multicast, publish-subscribe). Implementers of
this profile should make sure that their use case corresponds to the this profile should make sure that their use case corresponds to the
expected use of OSCORE, to prevent weakening the security assurances expected use of OSCORE, to prevent weakening the security assurances
provided by OSCORE. provided by OSCORE.
Since the use of nonces in the exchange guarantees uniqueness of AEAD Since the use of nonces N1 and N2 during the exchange guarantees
keys and nonces, it is REQUIRED that nonces are not reused with the uniqueness of AEAD keys and nonces, it is REQUIRED that the exchanged
same input keying material even in case of re-boots. This document nonces are not reused with the same input keying material even in
RECOMMENDS the use of 64 bit random nonces. Considering the birthday case of re-boots. This document RECOMMENDS the exchange of 64 bit
paradox, the average collision for each nonce will happen after 2^32 random nonces. Considering the birthday paradox, the average
messages, which is considerably more token provisionings than collision for each nonce will happen after 2^32 messages, which is
expected for intended applications. If applications use something considerably more token provisionings than expected for intended
else, such as a counter, they need to guarantee that reboot and loss applications. If applications use something else, such as a counter,
of state on either node does not provoke reuse. If that is not they need to guarantee that reboot and loss of state on either node
guaranteed, nodes are susceptible to reuse of AEAD (nonces, keys) does not provoke reuse. If that is not guaranteed, nodes are
pairs, especially since an on-path attacker can cause the client to susceptible to reuse of AEAD (nonce, key) pairs, especially since an
use an arbitrary nonce for Security Context establishment by on-path attacker can cause the use of a previously exchanged client
replaying client-to-server messages. nonce N1 for Security Context establishment by replaying the
corresponding client-to-server message.
This profile recommends that the RS maintains a single access token This profile recommends that the RS maintains a single access token
for each client. The use of multiple access tokens for a single for each client. The use of multiple access tokens for a single
client increases the strain on the resource server as it must client increases the strain on the resource server as it must
consider every access token and calculate the actual permissions of consider every access token and calculate the actual permissions of
the client. Also, tokens indicating different or disjoint the client. Also, tokens indicating different or disjoint
permissions from each other may lead the server to enforce wrong permissions from each other may lead the server to enforce wrong
permissions. If one of the access tokens expires earlier than permissions. If one of the access tokens expires earlier than
others, the resulting permissions may offer insufficient protection. others, the resulting permissions may offer insufficient protection.
Developers should avoid using multiple access tokens for a same Developers should avoid using multiple access tokens for a same
skipping to change at page 30, line 26 skipping to change at page 30, line 26
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)", draft-ietf-ace-oauth-authz-36
(work in progress), November 2020. (work in progress), November 2020.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-13 (work in progress), April 2020. params-13 (work in progress), April 2020.
[I-D.ietf-cbor-7049bis]
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work
in progress), September 2020.
[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>.
skipping to change at page 31, line 16 skipping to change at page 31, line 10
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References 10.2. Informative References
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
 End of changes. 19 change blocks. 
67 lines changed or deleted 70 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/