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/