draft-ietf-ace-dtls-authorize-14.txt   draft-ietf-ace-dtls-authorize-15.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft O. Bergmann Internet-Draft O. Bergmann
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: May 2, 2021 Universitaet Bremen TZI Expires: 24 July 2021 Universität Bremen TZI
G. Selander G. Selander
Ericsson AB Ericsson AB
L. Seitz L. Seitz
Combitech Combitech
October 29, 2020 20 January 2021
Datagram Transport Layer Security (DTLS) Profile for Authentication and Datagram Transport Layer Security (DTLS) Profile for Authentication and
Authorization for Constrained Environments (ACE) Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-14 draft-ietf-ace-dtls-authorize-15
Abstract Abstract
This specification defines a profile of the ACE framework that allows This specification defines a profile of the ACE framework that allows
constrained servers to delegate client authentication and constrained servers to delegate client authentication and
authorization. The protocol relies on DTLS version 1.2 for authorization. The protocol relies on DTLS version 1.2 for
communication security between entities in a constrained network communication security between entities in a constrained network
using either raw public keys or pre-shared keys. A resource- using either raw public keys or pre-shared keys. A resource-
constrained server can use this protocol to delegate management of constrained server can use this protocol to delegate management of
authorization information to a trusted host with less severe authorization information to a trusted host with less severe
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 May 2, 2021. This Internet-Draft will expire on 24 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Communication Between the Client and the Authorization 3.1. Communication Between the Client and the Authorization
Server . . . . . . . . . . . . . . . . . . . . . . . . . 6 Server . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 7 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Access Token Retrieval from the Authorization Server 7 3.2.1. Access Token Retrieval from the Authorization
3.2.2. DTLS Channel Setup Between Client and Resource Server 9 Server . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. DTLS Channel Setup Between Client and Resource
Server . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Access Token Retrieval from the Authorization Server 10 3.3.1. Access Token Retrieval from the Authorization
3.3.2. DTLS Channel Setup Between Client and Resource Server 14 Server . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. DTLS Channel Setup Between Client and Resource
Server . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16
4. Dynamic Update of Authorization Information . . . . . . . . . 18 4. Dynamic Update of Authorization Information . . . . . . . . . 18
5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19
6. Secure Communication with an Authorization Server . . . . . . 19 6. Secure Communication with an Authorization Server . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21 7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21
7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22 7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22
7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22 7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This specification defines a profile of the ACE framework This specification defines a profile of the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to
communicate. The client obtains an access token, bound to a key (the communicate. The client obtains an access token, bound to a key (the
proof-of-possession key), from an authorization server to prove its proof-of-possession key), from an authorization server to prove its
authorization to access protected resources hosted by the resource authorization to access protected resources hosted by the resource
server. Also, the client and the resource server are provided by the server. Also, the client and the resource server are provided by the
skipping to change at page 4, line 40 skipping to change at page 4, line 52
C RS AS C RS AS
| [---- Resource Request ------>]| | | [---- Resource Request ------>]| |
| | | | | |
| [<-AS Request Creation Hints-] | | | [<-AS Request Creation Hints-] | |
| | | | | |
| ------- Token Request ----------------------------> | | ------- Token Request ----------------------------> |
| | | | | |
| <---------------------------- Access Token --------- | | <---------------------------- Access Token --------- |
| + Access Information | | + Access Information |
Figure 1: Retrieving an Access Token Figure 1: Retrieving an Access Token
To determine the authorization server in charge of a resource hosted To determine the authorization server in charge of a resource hosted
at the resource server, the client can send an initial Unauthorized at the resource server, the client can send an initial Unauthorized
Resource Request message to the resource server. The resource server Resource Request message to the resource server. The resource server
then denies the request and sends an AS Request Creation Hints then denies the request and sends an AS Request Creation Hints
message containing the address of its authorization server back to message containing the address of its authorization server back to
the client as specified in Section 5.1.2 of the client as specified in Section 5.1.2 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Once the client knows the authorization server's address, it can send Once the client knows the authorization server's address, it can send
skipping to change at page 6, line 26 skipping to change at page 6, line 35
To retrieve an access token for the resource that the client wants to To retrieve an access token for the resource that the client wants to
access, the client requests an access token from the authorization access, the client requests an access token from the authorization
server. Before the client can request the access token, the client server. Before the client can request the access token, the client
and the authorization server MUST establish a secure communication and the authorization server MUST establish a secure communication
channel. This profile assumes that the keying material to secure channel. This profile assumes that the keying material to secure
this communication channel has securely been obtained either by this communication channel has securely been obtained either by
manual configuration or in an automated provisioning process. The manual configuration or in an automated provisioning process. The
following requirements in alignment with Section 6.5 of following requirements in alignment with Section 6.5 of
[I-D.ietf-ace-oauth-authz] therefore must be met: [I-D.ietf-ace-oauth-authz] therefore must be met:
o The client MUST securely have obtained keying material to * The client MUST securely have obtained keying material to
communicate with the authorization server. communicate with the authorization server.
o Furthermore, the client MUST verify that the authorization server * Furthermore, the client MUST verify that the authorization server
is authorized to provide access tokens (including authorization is authorized to provide access tokens (including authorization
information) about the resource server to the client, and that information) about the resource server to the client, and that
this authorization information about the authorization server is this authorization information about the authorization server is
still valid. still valid.
o Also, the authorization server MUST securely have obtained keying * Also, the authorization server MUST securely have obtained keying
material for the client, and obtained authorization rules approved material for the client, and obtained authorization rules approved
by the resource owner (RO) concerning the client and the resource by the resource owner (RO) concerning the client and the resource
server that relate to this keying material. server that relate to this keying material.
The client and the authorization server MUST use their respective The client and the authorization server MUST use their respective
keying material for all exchanged messages. How the security keying material for all exchanged messages. How the security
association between the client and the authorization server is association between the client and the authorization server is
bootstrapped is not part of this document. The client and the bootstrapped is not part of this document. The client and the
authorization server must ensure the confidentiality, integrity and authorization server must ensure the confidentiality, integrity and
authenticity of all exchanged messages within the ACE protocol. authenticity of all exchanged messages within the ACE protocol.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
rs_cnf : { rs_cnf : {
COSE_Key : { COSE_Key : {
kty : EC2, kty : EC2,
crv : P-256, crv : P-256,
x : h'd7cc072de2205bdc1537...', x : h'd7cc072de2205bdc1537...',
y : h'f95e1d4b851a2cc80fff...' y : h'f95e1d4b851a2cc80fff...'
} }
} }
} }
Figure 4: Access Token Response Example for RPK Mode Figure 4: Access Token Response Example for RPK Mode
3.2.2. DTLS Channel Setup Between Client and Resource Server 3.2.2. DTLS Channel Setup Between Client and Resource Server
Before the client initiates the DTLS handshake with the resource Before the client initiates the DTLS handshake with the resource
server, the client MUST send a "POST" request containing the obtained server, the client MUST send a "POST" request containing the obtained
access token to the authz-info resource hosted by the resource access token to the authz-info resource hosted by the resource
server. After the client receives a confirmation that the resource server. After the client receives a confirmation that the resource
server has accepted the access token, it SHOULD proceed to establish server has accepted the access token, it SHOULD proceed to establish
a new DTLS channel with the resource server. The client MUST use its a new DTLS channel with the resource server. The client MUST use its
correct public key in the DTLS handshake. If the authorization correct public key in the DTLS handshake. If the authorization
skipping to change at page 11, line 41 skipping to change at page 11, line 41
An example access token request for an access token with a symmetric An example access token request for an access token with a symmetric
proof-of-possession key is illustrated in Figure 5. proof-of-possession key is illustrated in Figure 5.
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
audience : "smokeSensor1807", audience : "smokeSensor1807",
} }
Figure 5: Example Access Token Request, (implicit) symmetric PoP-key Figure 5: Example Access Token Request, (implicit) symmetric PoP-key
A corresponding example access token response is illustrated in A corresponding example access token response is illustrated in
Figure 6. In this example, the authorization server returns a 2.01 Figure 6. In this example, the authorization server returns a 2.01
response containing a new access token (truncated to improve response containing a new access token (truncated to improve
readability) and information for the client, including the symmetric readability) and information for the client, including the symmetric
key in the cnf claim. The information is transferred as a CBOR data key in the cnf claim. The information is transferred as a CBOR data
structure as specified in [I-D.ietf-ace-oauth-authz]. structure as specified in [I-D.ietf-ace-oauth-authz].
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
skipping to change at page 12, line 24 skipping to change at page 12, line 24
profile : coap_dtls, profile : coap_dtls,
cnf : { cnf : {
COSE_Key : { COSE_Key : {
kty : symmetric, kty : symmetric,
kid : h'3d027833fc6267ce', kid : h'3d027833fc6267ce',
k : h'73657373696f6e6b6579' k : h'73657373696f6e6b6579'
} }
} }
} }
Figure 6: Example Access Token Response, symmetric PoP-key Figure 6: Example Access Token Response, symmetric PoP-key
The access token also comprises a "cnf" claim. This claim usually The access token also comprises a "cnf" claim. This claim usually
contains a "COSE_Key" object that carries either the symmetric key contains a "COSE_Key" object that carries either the symmetric key
itself or a key identifier that can be used by the resource server to itself or a key identifier that can be used by the resource server to
determine the secret key it shares with the client. If the access determine the secret key it shares with the client. If the access
token carries a symmetric key, the access token MUST be encrypted token carries a symmetric key, the access token MUST be encrypted
using a "COSE_Encrypt0" structure. The authorization server MUST use using a "COSE_Encrypt0" structure. The authorization server MUST use
the keying material shared with the resource server to encrypt the the keying material shared with the resource server to encrypt the
token. token.
The "cnf" structure in the access token is provided in Figure 7. The "cnf" structure in the access token is provided in Figure 7.
cnf : { cnf : {
COSE_Key : { COSE_Key : {
kty : symmetric, kty : symmetric,
kid : h'3d027833fc6267ce' kid : h'3d027833fc6267ce'
} }
} }
Figure 7: Access Token without Keying Material Figure 7: Access Token without Keying Material
A response that declines any operation on the requested resource is A response that declines any operation on the requested resource is
constructed according to Section 5.2 of [RFC6749], (cf. constructed according to Section 5.2 of [RFC6749], (cf.
Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). Figure 8 shows an Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). Figure 8 shows an
example for a request that has been rejected due to invalid request example for a request that has been rejected due to invalid request
parameters. parameters.
4.00 Bad Request 4.00 Bad Request
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
unique symmetric key is required. unique symmetric key is required.
In this example, HKDF consists of the composition of the HKDF-Extract In this example, HKDF consists of the composition of the HKDF-Extract
and HKDF-Expand steps [RFC5869]. The symmetric key is derived from and HKDF-Expand steps [RFC5869]. The symmetric key is derived from
the key identifier, the key derivation key and other data: the key identifier, the key derivation key and other data:
OKM = HKDF(salt, IKM, info, L), OKM = HKDF(salt, IKM, info, L),
where: where:
o OKM, the output keying material, is the derived symmetric key * OKM, the output keying material, is the derived symmetric key
o salt is the empty byte string * salt is the empty byte string
o IKM, the input keying material, is the key derivation key as * IKM, the input keying material, is the key derivation key as
defined above defined above
o info is the serialization of a CBOR array consisting of * info is the serialization of a CBOR array consisting of
([RFC8610]): ([RFC8610]):
info = [ info = [
type : tstr, type : tstr,
L : uint, L : uint,
access_token: bytes access_token: bytes
] ]
where: where:
o type is set to the constant text string "ACE-CoAP-DTLS-key- * type is set to the constant text string "ACE-CoAP-DTLS-key-
derivation", derivation",
o L is the size of the symmetric key in bytes, * L is the size of the symmetric key in bytes,
o access_token is the content of the "access_token" field as * access_token is the content of the "access_token" field as
transferred from the authorization server to the resource server. transferred from the authorization server to the resource server.
All CBOR data types are encoded in CBOR using preferred serialization All CBOR data types are encoded in CBOR using preferred serialization
and deterministic encoding as specified in Section 4 of and deterministic encoding as specified in Section 4 of [RFC8949].
[I-D.ietf-cbor-7049bis]. This implies in particular that the "type" This implies in particular that the "type" and "L" components use the
and "L" components use the minimum length encoding. The content of minimum length encoding. The content of the "access_token" field is
the "access_token" field is treated as opaque data for the purpose of treated as opaque data for the purpose of key derivation.
key derivation.
Use of a unique (per resource server) "kid" and the use of a key Use of a unique (per resource server) "kid" and the use of a key
derivation IKM that MUST be unique per authorization server/resource derivation IKM that MUST be unique per authorization server/resource
server pair as specified above will ensure that the derived key is server pair as specified above will ensure that the derived key is
not shared across multiple clients. However, to additionally provide not shared across multiple clients. However, to additionally provide
variation in the derived key across different tokens used by the same variation in the derived key across different tokens used by the same
client, it is additionally RECOMMENDED to include the "iat" claim and client, it is additionally RECOMMENDED to include the "iat" claim and
either the "exp" or "exi" claims in the access token. either the "exp" or "exi" claims in the access token.
3.3.2. DTLS Channel Setup Between Client and Resource Server 3.3.2. DTLS Channel Setup Between Client and Resource Server
skipping to change at page 15, line 38 skipping to change at page 15, line 38
that is used as value for "psk_identity" as shown in Figure 9. that is used as value for "psk_identity" as shown in Figure 9.
{ cnf : { { cnf : {
COSE_Key : { COSE_Key : {
kty: symmetric, kty: symmetric,
kid : h'3d027833fc6267ce' kid : h'3d027833fc6267ce'
} }
} }
} }
Figure 9: Access token containing a single kid parameter Figure 9: Access token containing a single kid parameter
As an alternative to the access token upload, the client can provide As an alternative to the access token upload, the client can provide
the most recent access token in the "psk_identity" field of the the most recent access token in the "psk_identity" field of the
ClientKeyExchange message. To do so, the client MUST treat the ClientKeyExchange message. To do so, the client MUST treat the
contents of the "access_token" field from the AS-to-Client response contents of the "access_token" field from the AS-to-Client response
as opaque data as specified in Section 4.2 of [RFC7925] and not as opaque data as specified in Section 4.2 of [RFC7925] and not
perform any re-coding. This allows the resource server to retrieve perform any re-coding. This allows the resource server to retrieve
the shared secret directly from the "cnf" claim of the access token. the shared secret directly from the "cnf" claim of the access token.
If a resource server receives a ClientKeyExchange message that If a resource server receives a ClientKeyExchange message that
contains a "psk_identity" with a length greater than zero, it MUST contains a "psk_identity" with a length greater than zero, it MUST
parse the contents of the "psk_identity" field as CBOR data structure parse the contents of the "psk_identity" field as CBOR data structure
and process the contents as following: and process the contents as following:
o If the data contains a "cnf" field with a "COSE_Key" structure * If the data contains a "cnf" field with a "COSE_Key" structure
with a "kid", the resource server continues the DTLS handshake with a "kid", the resource server continues the DTLS handshake
with the associated key that corresponds to this kid. with the associated key that corresponds to this kid.
o If the data comprises additional CWT information, this information * If the data comprises additional CWT information, this information
must be stored as an access token for this DTLS association before must be stored as an access token for this DTLS association before
continuing with the DTLS handshake. continuing with the DTLS handshake.
If the contents of the "psk_identity" do not yield sufficient If the contents of the "psk_identity" do not yield sufficient
information to select a valid access token for the requesting client, information to select a valid access token for the requesting client,
the resource server aborts the DTLS handshake with an the resource server aborts the DTLS handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
When the resource server receives an access token, it MUST check if When the resource server receives an access token, it MUST check if
the access token is still valid, if the resource server is the the access token is still valid, if the resource server is the
skipping to change at page 20, line 5 skipping to change at page 20, line 11
resource server MUST notify the client with an error response with resource server MUST notify the client with an error response with
code 4.01 (Unauthorized) for any long running request before code 4.01 (Unauthorized) for any long running request before
terminating the association. terminating the association.
6. Secure Communication with an Authorization Server 6. Secure Communication with an Authorization Server
As specified in the ACE framework (Sections 5.6 and 5.7 of As specified in the ACE framework (Sections 5.6 and 5.7 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (the resource [I-D.ietf-ace-oauth-authz]), the requesting entity (the resource
server and/or the client) and the authorization server communicate server and/or the client) and the authorization server communicate
via the token endpoint or introspection endpoint. The use of CoAP via the token endpoint or introspection endpoint. The use of CoAP
and DTLS for this communication is RECOMMENDED in this profile, other and DTLS for this communication is REQUIRED in this profile. Other
protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will
used instead. require specification of additional profile(s).
How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the
authorization server are established is out of scope for this authorization server are established is out of scope for this
profile. profile.
If other means of securing the communication with the authorization If other means of securing the communication with the authorization
server are used, the communication security requirements from server are used, the communication security requirements from
Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable. Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable.
7. Security Considerations 7. Security Considerations
skipping to change at page 24, line 22 skipping to change at page 24, line 25
projects CyberWI, and CRITISEC with funding from Vinnova. projects CyberWI, and CRITISEC with funding from Vinnova.
11. References 11. References
11.1. Normative References 11.1. Normative 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-35 Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
(work in progress), June 2020. draft-ietf-ace-oauth-authz-36, 16 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
authz-36.txt>.
[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)", Work in Progress,
params-13 (work in progress), April 2020. Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
[I-D.ietf-cbor-7049bis] oauth-params-13.txt>.
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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
skipping to change at page 25, line 46 skipping to change at page 26, line 5
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
[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>.
11.2. Informative References 11.2. Informative References
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
skipping to change at page 26, line 46 skipping to change at page 27, line 13
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>.
Authors' Addresses Authors' Addresses
Stefanie Gerdes Stefanie Gerdes
Universitaet Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 D-28359 Bremen
Germany Germany
Phone: +49-421-218-63906 Phone: +49-421-218-63906
Email: gerdes@tzi.org Email: gerdes@tzi.org
Olaf Bergmann Olaf Bergmann
Universitaet Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 D-28359 Bremen
Germany Germany
Phone: +49-421-218-63904 Phone: +49-421-218-63904
Email: bergmann@tzi.org Email: bergmann@tzi.org
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Goeran Selander Göran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Ludwig Seitz Ludwig Seitz
Combitech Combitech
Djaeknegatan 31 Djäknegatan 31
Malmoe 211 35 SE-211 35 Malmö
Sweden Sweden
Email: ludwig.seitz@combitech.se Email: ludwig.seitz@combitech.se
 End of changes. 45 change blocks. 
68 lines changed or deleted 74 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/