draft-tiloca-ace-group-oscore-profile-04.txt   draft-tiloca-ace-group-oscore-profile-05.txt 
ACE Working Group M. Tiloca ACE Working Group M. Tiloca
Internet-Draft R. Hoeglund Internet-Draft R. Hoeglund
Intended status: Standards Track RISE AB Intended status: Standards Track RISE AB
Expires: May 6, 2021 L. Seitz Expires: August 26, 2021 L. Seitz
Combitech Combitech
F. Palombini F. Palombini
Ericsson AB Ericsson AB
November 02, 2020 February 22, 2021
Group OSCORE Profile of the Authentication and Authorization for Group OSCORE Profile of the Authentication and Authorization for
Constrained Environments Framework Constrained Environments Framework
draft-tiloca-ace-group-oscore-profile-04 draft-tiloca-ace-group-oscore-profile-05
Abstract Abstract
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. The Authorization for Constrained Environments (ACE) framework. The
profile uses Group OSCORE to provide communication security between a profile uses Group OSCORE to provide communication security between a
Client and a (set of) Resource Server(s) as members of an OSCORE Client and a (set of) Resource Server(s) as members of an OSCORE
Group. The profile securely binds an OAuth 2.0 Access Token with the Group. The profile securely binds an OAuth 2.0 Access Token with the
public key of the Client associated to the signing private key used public key of the Client associated to the signing private key used
in the OSCORE group. The profile uses Group OSCORE to achieve server in the OSCORE group. The profile uses Group OSCORE to achieve server
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 6, 2021. This Internet-Draft will expire on August 26, 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/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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 9 2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 8
2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 9 2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 9
2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 10 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 9
2.4. Secure Communication . . . . . . . . . . . . . . . . . . 10 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 10
3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 11 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 10
3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 11 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 10
3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 13 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 12
3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 13 3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 12
3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 13 3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 13
3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 14 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 13
3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 17 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 16
3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 17 3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 17
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17
4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 18 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 18
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18
4.3. Client-RS Secure Communication . . . . . . . . . . . . . 19 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 19
4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 19
4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 19 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 20
4.4. Access Rights Verification . . . . . . . . . . . . . . . 20 4.4. Access Rights Verification . . . . . . . . . . . . . . . 20
5. Secure Communication with the AS . . . . . . . . . . . . . . 20 4.5. Change of Client's Public Key in the Group . . . . . . . 21
6. Discarding the Security Context . . . . . . . . . . . . . . . 21 5. Secure Communication with the AS . . . . . . . . . . . . . . 21
7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Discarding the Security Context . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 23 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 24
10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 24 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 25
10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 25 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 25
10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 26 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30
A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 31
A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 32 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 32 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 34
A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 33 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 34
A.1.4. Secure Communication . . . . . . . . . . . . . . . . 34 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 34
A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 34 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 35
A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 35 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 36
A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 37 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 36
A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 44 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 39
A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 45 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 45
A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 46 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 46
A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 46 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 47
A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 49 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 48
A.3.5. Access Rights Verification . . . . . . . . . . . . . 51 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 51
A.4. Secure Communication with the AS . . . . . . . . . . . . 51 A.3.5. Access Rights Verification . . . . . . . . . . . . . 53
A.5. Discarding the Security Context . . . . . . . . . . . . . 51 A.3.6. Change of Client's Public Key in the Group . . . . . 53
A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 52 A.4. Secure Communication with the AS . . . . . . . . . . . . 54
A.7. Security Considerations . . . . . . . . . . . . . . . . . 52 A.5. Discarding the Security Context . . . . . . . . . . . . . 54
A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 52 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 55
Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 53 A.7. Security Considerations . . . . . . . . . . . . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 56
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
A number of applications rely on a group communication model, where a A number of applications rely on a group communication model, where a
Client can access a resource shared by multiple Resource Servers at Client can access a resource shared by multiple Resource Servers at
once, e.g. over IP multicast. Typical examples are switching of once, e.g. over IP multicast. Typical examples are switching of
luminaries, actuators control, and distribution of software updates. luminaries, actuators control, and distribution of software updates.
Secure communication in the group can be achieved by sharing a set of Secure communication in the group can be achieved by sharing a set of
key material, which is typically provided upon joining the group. key material, which is typically provided upon joining the group.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
related to CBOR [I-D.ietf-cbor-7049bis], COSE related to CBOR [RFC8949], COSE
[I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs],
CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. These include the concept of Group [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group
Manager, as the entity responsible for a set of groups where Manager, as the entity responsible for a set of groups where
communications among members are secured with Group OSCORE. communications among members are secured with Group OSCORE.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in the ACE framework for authentication and authorization described in the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile]. The terminology for entities in the [I-D.ietf-ace-oscore-profile]. The terminology for entities in the
skipping to change at page 8, line 43 skipping to change at page 8, line 15
|-- Group OSCORE Request -+-->| | | |-- Group OSCORE Request -+-->| | |
| (kid: 0, gid: abcd0000) \-------------->| | | (kid: 0, gid: abcd0000) \-------------->| |
| | | | | | | |
| /proof-of-possession/ | | /proof-of-possession/ |
| | | | | | | |
|<--- Group OSCORE Response --| | | |<--- Group OSCORE Response --| | |
| (kid: 1) | | | | (kid: 1) | | |
| | | | | | | |
/proof-of-possession/ | | | /proof-of-possession/ | | |
| | | | | | | |
/Mutual authentication | | |
between C and RS1/ | | |
| | | |
| | | |
|<--- Group OSCORE Response ---------------| | |<--- Group OSCORE Response ---------------| |
| (kid: 2) | | | | (kid: 2) | | |
| | | | | | | |
/proof-of-possession/ | | | /proof-of-possession/ | | |
| | | |
/Mutual authentication | | |
between C and RS2/ | | |
| | | |
| ... | | | | ... | | |
Figure 1: Protocol Overview. Figure 1: Protocol Overview.
2.1. Pre-Conditions 2.1. Pre-Conditions
Using Group OSCORE and this profile requires both the Client and the Using Group OSCORE and this profile requires both the Client and the
Resource Servers to have previously joined the same OSCORE group. Resource Servers to have previously joined the same OSCORE group.
This especially includes the derivation of the Group OSCORE Security This especially includes the derivation of the Group OSCORE Security
Context and the assignment of unique Sender IDs to use in the group. Context and the assignment of unique Sender IDs to use in the group.
skipping to change at page 9, line 30 skipping to change at page 9, line 9
successfully joined the OSCORE group where also the Resource Servers successfully joined the OSCORE group where also the Resource Servers
(RSs) are members. Depending on the limited information initially (RSs) are members. Depending on the limited information initially
available, the Client may have to first discover the exact OSCORE available, the Client may have to first discover the exact OSCORE
group used by the RSs for the resources of interest, e.g. by using group used by the RSs for the resources of interest, e.g. by using
the approach defined in [I-D.tiloca-core-oscore-discovery]. the approach defined in [I-D.tiloca-core-oscore-discovery].
2.2. Access Token Retrieval 2.2. Access Token Retrieval
This profile requires that the Client retrieves an Access Token from This profile requires that the Client retrieves an Access Token from
the AS for the resource(s) it wants to access on each of the RSs, the AS for the resource(s) it wants to access on each of the RSs,
using the /token endpoint, as specified in Section 5.6 of using the /token endpoint, as specified in Section 5.8 of
[I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed
that different RSs are associated to different ASs, even if the RSs that different RSs are associated to different ASs, even if the RSs
are members of a same OSCORE group. are members of a same OSCORE group.
In the Access Token request to the AS, the Client MUST include the In the Access Token request to the AS, the Client MUST include the
Group Identifier of the OSCORE group and its own Sender ID in that Group Identifier of the OSCORE group and its own Sender ID in that
group. The AS MUST specify these pieces of information in the Access group. The AS MUST specify these pieces of information in the Access
Token, included in the Access Token response to the Client. Token, included in the Access Token response to the Client.
Furthermore, in the Access Token request to the AS, the Client MUST Furthermore, in the Access Token request to the AS, the Client MUST
also include: its own public key, associated to the private signing also include: its own public key, associated to the private signing
key used in the OSCORE group; and a signature computed with such key used in the OSCORE group; and a signature computed with such
private key, over a quantity uniquely related to the secure private key, over a quantity uniquely related to the secure
communication association between the Client and the AS. The AS MUST communication association between the Client and the AS. The AS MUST
include also the public key indicated by the Client in the Access include also the public key indicated by the Client in the Access
Token. Token.
The Access Token request and response MUST be confidentiality- The Access Token request and response MUST be confidentiality-
protected and ensure authenticity. This profile RECOMMENDS the use protected and ensure authenticity. This profile RECOMMENDS the use
of OSCORE between the Client and the AS, but TLS [RFC5246][RFC8446] of OSCORE between the Client and the AS, to reduce the number of
or DTLS [RFC6347][I-D.ietf-tls-dtls13] MAY be used additionally or libraries the client has to support. Other protocols fulfilling the
instead. security requirements defined in Section 5 of
[I-D.ietf-ace-oauth-authz] (such as TLS [RFC8446] or DTLS
[RFC6347][I-D.ietf-tls-dtls13]) MAY be used additionally or instead.
2.3. Access Token Posting 2.3. Access Token Posting
After having retrieved the Access Token from the AS, the Client posts After having retrieved the Access Token from the AS, the Client posts
the Access Token to the RS, using the /authz-info endpoint and the Access Token to the RS, using the /authz-info endpoint and
mechanisms specified in Section 5.8 of [I-D.ietf-ace-oauth-authz], as mechanisms specified in Section 5.10 of [I-D.ietf-ace-oauth-authz],
well as Content-Format = application/ace+cbor. When using this as well as Content-Format = application/ace+cbor. When using this
profile, the communication with the /authz-info endpoint is not profile, the communication with the /authz-info endpoint is not
protected. protected.
If the Access Token is valid, the RS replies to this POST request If the Access Token is valid, the RS replies to this POST request
with a 2.01 (Created) response with Content-Format = application/ with a 2.01 (Created) response with Content-Format = application/
ace+cbor. Also, the RS associates the received Access Token with the ace+cbor. Also, the RS associates the received Access Token with the
Group OSCORE Security Context identified by the Group Identifier Group OSCORE Security Context identified by the Group Identifier
specified in the Access Token, following Section 3.2 of [RFC8613]. specified in the Access Token, following Section 3.2 of [RFC8613].
In practice, the RS maintains a collection of Security Contexts with In practice, the RS maintains a collection of Security Contexts with
associated authorization information, for all the clients that it is associated authorization information, for all the clients that it is
skipping to change at page 11, line 16 skipping to change at page 10, line 42
This section details the Access Token POST Request that the Client This section details the Access Token POST Request that the Client
sends to the /token endpoint of the AS, as well as the related Access sends to the /token endpoint of the AS, as well as the related Access
Token response. Token response.
The Access Token MUST be bound to the public key of the client as The Access Token MUST be bound to the public key of the client as
proof-of-possession key (pop-key), by means of the 'cnf' claim. proof-of-possession key (pop-key), by means of the 'cnf' claim.
3.1. C-to-AS: POST to Token Endpoint 3.1. C-to-AS: POST to Token Endpoint
The Client-to-AS request is specified in Section 5.6.1 of The Client-to-AS request is specified in Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request
to the /token endpoint over a secure channel that guarantees to the /token endpoint over a secure channel that guarantees
authentication, message integrity and confidentiality. authentication, message integrity and confidentiality.
The POST request is formatted as the analogous Client-to-AS request The POST request is formatted as the analogous Client-to-AS request
in the OSCORE profile of ACE (see Section 3.1 of in the OSCORE profile of ACE (see Section 3.1 of
[I-D.ietf-ace-oscore-profile]), with the following additional [I-D.ietf-ace-oscore-profile]), with the following additional
parameters that MUST be included in the payload. parameters that MUST be included in the payload.
o 'context_id', defined in Section 3.1.1 of this specification. o 'context_id', defined in Section 3.1.1 of this specification.
skipping to change at page 13, line 35 skipping to change at page 12, line 39
"client_cred_verify" : h'...' "client_cred_verify" : h'...'
(signature content omitted for brevity) (signature content omitted for brevity)
} }
Figure 2: Example C-to-AS POST /token request for an Access Token Figure 2: Example C-to-AS POST /token request for an Access Token
bound to an asymmetric key. bound to an asymmetric key.
3.1.1. 'context_id' Parameter 3.1.1. 'context_id' Parameter
The 'context_id' parameter is an OPTIONAL parameter of the Access The 'context_id' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of Token request message defined in Section 5.8.1. of
[I-D.ietf-ace-oauth-authz]. This parameter provides a value that the [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the
Client wishes to use with the RS as a hint for a security context. Client wishes to use with the RS as a hint for a security context.
Its exact content is profile specific. Its exact content is profile specific.
3.1.2. 'salt_input' Parameter 3.1.2. 'salt_input' Parameter
The 'salt_input' parameter is an OPTIONAL parameter of the Access The 'salt_input' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of Token request message defined in Section 5.8.1. of
[I-D.ietf-ace-oauth-authz]. This parameter provides a value that the [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the
Client wishes to use as part of a salt with the RS, for deriving Client wishes to use as part of a salt with the RS, for deriving
cryptographic key material. Its exact content is profile specific. cryptographic key material. Its exact content is profile specific.
3.1.3. 'client_cred_verify' Parameter 3.1.3. 'client_cred_verify' Parameter
The 'client_cred_verify' parameter is an OPTIONAL parameter of the The 'client_cred_verify' parameter is an OPTIONAL parameter of the
Access Token request message defined in Section 5.6.1. of Access Token request message defined in Section 5.8.1. of
[I-D.ietf-ace-oauth-authz]. This parameter provides a signature [I-D.ietf-ace-oauth-authz]. This parameter provides a signature
computed by the Client to prove the possession of its own private computed by the Client to prove the possession of its own private
key. key.
3.2. AS-to-C: Access Token 3.2. AS-to-C: Access Token
After having verified the POST request to the /token endpoint and After having verified the POST request to the /token endpoint and
that the Client is authorized to obtain an Access Token corresponding that the Client is authorized to obtain an Access Token corresponding
to its Access Token request, the AS MUST verify the signature in the to its Access Token request, the AS MUST verify the signature in the
'client_cred_verify' parameter, by using the public key specified in 'client_cred_verify' parameter, by using the public key specified in
the 'req_cnf' parameter. If the verification fails, the AS considers the 'req_cnf' parameter. If the verification fails, the AS considers
the Client request invalid. the Client request invalid.
If all verifications are successful, the AS responds as defined in If all verifications are successful, the AS responds as defined in
Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request
was invalid, or not authorized, the AS returns an error response as was invalid, or not authorized, the AS returns an error response as
described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz].
The AS can signal that the use of Group OSCORE is REQUIRED for a The AS can signal that the use of Group OSCORE is REQUIRED for a
specific Access Token by including the 'profile' parameter with the specific Access Token by including the 'profile' parameter with the
value "coap_group_oscore" in the Access Token response. The Client value "coap_group_oscore" in the Access Token response. The Client
MUST use Group OSCORE towards all the Resource Servers for which this MUST use Group OSCORE towards all the Resource Servers for which this
Access Token is valid. Usually, it is assumed that constrained Access Token is valid. Usually, it is assumed that constrained
devices will be pre-configured with the necessary profile, so that devices will be pre-configured with the necessary profile, so that
this kind of profile negotiation can be omitted. this kind of profile signaling can be omitted.
The AS MUST include the following information as metadata of the The AS MUST include the following information as metadata of the
issued Access Token. The use of CBOR web tokens (CWT) as specified issued Access Token. The use of CBOR web tokens (CWT) as specified
in [RFC8392] is RECOMMENDED. in [RFC8392] is RECOMMENDED.
o The same parameter 'profile' included in the Token Response to the o The same parameter 'profile' included in the Token Response to the
Client. Client.
o The salt input specified in the 'salt_input' parameter of the o The salt input specified in the 'salt_input' parameter of the
Token Request. If the Access Token is a CWT, the content of the Token Request. If the Access Token is a CWT, the content of the
skipping to change at page 18, line 31 skipping to change at page 18, line 20
As a consequence, a different Client C2, also member of the same As a consequence, a different Client C2, also member of the same
OSCORE group, is not able to impersonate C1, by: i) getting a valid OSCORE group, is not able to impersonate C1, by: i) getting a valid
Access Token, specifying the Sender ID of C1 and a different (made- Access Token, specifying the Sender ID of C1 and a different (made-
up) public key; ii) successfully posting the Access Token to RS; and up) public key; ii) successfully posting the Access Token to RS; and
then iii) attempting to communicate using Group OSCORE impersonating then iii) attempting to communicate using Group OSCORE impersonating
C1, while blaming C1 for the consequences. C1, while blaming C1 for the consequences.
4.1. C-to-RS POST to authz-info Endpoint 4.1. C-to-RS POST to authz-info Endpoint
The Client posts the Access Token to the /authz-info endpoint of the The Client posts the Access Token to the /authz-info endpoint of the
RS, as defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. RS, as defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz].
4.2. RS-to-C: 2.01 (Created) 4.2. RS-to-C: 2.01 (Created)
The RS MUST verify the validity of the Access Token as defined in The RS MUST verify the validity of the Access Token as defined in
Section 5.8.1 of [I-D.ietf-ace-oauth-authz], with the following Section 5.10.1 of [I-D.ietf-ace-oauth-authz], with the following
additions. additions.
o The RS checks that the claims 'salt_input', 'contextId_input' and o The RS checks that the claims 'salt_input', 'contextId_input' and
'cnf' are included in the Access Token. 'cnf' are included in the Access Token.
o The RS considers the content of the 'cnf' claim as the public key o The RS considers the content of the 'cnf' claim as the public key
associated to the signing private key of the Client in the OSCORE associated to the signing private key of the Client in the OSCORE
group, whose GID is specified in the 'contextId_input' claim group, whose GID is specified in the 'contextId_input' claim.
above. If it does not already store that public key, the RS MUST
request it to the Group Manager of the OSCORE group as described If it does not already store that public key, the RS MUST request
in [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID it to the Group Manager of the OSCORE group as described in
of that Client in the OSCORE group, i.e. the value of the [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID of
that Client in the OSCORE group, i.e. the value of the
'salt_input' claim above. The RS MUST check that the key 'salt_input' claim above. The RS MUST check that the key
retrieved from the Group Manager matches the one retrieved from retrieved from the Group Manager matches the one retrieved from
the 'cnf' claim. When doing so, the 'kid' parameter of the the 'cnf' claim. When doing so, the 'kid' parameter of the
COSE_Key, if present, MUST NOT be considered for the comparison. COSE_Key, if present, MUST NOT be considered for the comparison.
If any of the checks above fails, the RS MUST consider the Access If any of the checks above fails, the RS MUST consider the Access
Token non valid, and MUST respond to the Client with an error Token non valid, and MUST respond to the Client with an error
response code equivalent to the CoAP code 4.00 (Bad Request). response code equivalent to the CoAP code 4.00 (Bad Request).
If the Access Token is valid and further checks on its content are If the Access Token is valid and further checks on its content are
successful, the RS associates the authorization information from the successful, the RS associates the authorization information from the
Access Token with the Group OSCORE Security Context. Access Token with the Group OSCORE Security Context.
In particular, the RS associates the authorization information from In particular, the RS associates the authorization information from
the Access Token with the tuple (GID, SaltInput, PubKey), where GID the Access Token with the 3-tuple (GID, SaltInput, PubKey), where GID
is the Group Identifier of the OSCORE Group, while SaltInput and is the Group Identifier of the OSCORE Group, while SaltInput and
PubKey are the Sender ID and the public key that the Client uses in PubKey are the Sender ID and the public key that the Client uses in
that OSCORE group, respectively. These can be retrieved from the that OSCORE group, respectively. These can be retrieved from the
'contextId_input', 'salt_input' and 'cnf' claims of the Access Token, 'contextId_input', 'salt_input' and 'cnf' claims of the Access Token,
respectively. The RS MUST keep this association up-to-date over respectively.
time.
The RS MUST keep this association up-to-date over time, as the
3-tuple (GID, SaltInput, PubKey) associated to the Access Token might
change. In particular:
o If the OSCORE group is rekeyed (see Section 3.1 of
[I-D.ietf-core-oscore-groupcomm] and Section 18 of
[I-D.ietf-ace-key-groupcomm-oscore]), the Group Identifier also
changes in the group, and the new one replaces the current 'GID'
value in the 3-tuple.
o If the Client requests and obtains a new OSCORE Sender ID from the
Group Manager (see Section 3.1 of [I-D.ietf-core-oscore-groupcomm]
and Section 9 of [I-D.ietf-ace-key-groupcomm-oscore]), the new
Sender ID replaces the current 'SaltInput' value in the 3-tuple.
Finally, the RS MUST send a 2.01 (Created) response to the Client, as Finally, the RS MUST send a 2.01 (Created) response to the Client, as
defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz].
4.3. Client-RS Secure Communication 4.3. Client-RS Secure Communication
When previously joining the OSCORE group, both the Client and RS have When previously joining the OSCORE group, both the Client and RS have
already established the related Group OSCORE Security Context to already established the related Group OSCORE Security Context to
communicate as group members. Therefore, they can simply start to communicate as group members. Therefore, they can simply start to
securely communicate using Group OSCORE, without deriving any securely communicate using Group OSCORE, without deriving any
additional key material or security association. additional key material or security association.
4.3.1. Client Side 4.3.1. Client Side
After having received the 2.01 (Created) response from the RS, After having received the 2.01 (Created) response from the RS,
following the POST request to the authz-info endpoint, the Client can following the POST request to the authz-info endpoint, the Client
start to communicate with the RS using Group OSCORE starts the communication with the RS, by sending a request protected
with Group OSCORE using the Group OSCORE Security Context
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
When communicating with the RS to access the resources as specified When communicating with the RS to access the resources as specified
by the authorization information, the Client MUST use the Group by the authorization information, the Client MUST use the Group
OSCORE Security Context of the OSCORE group, whose GID was specified OSCORE Security Context of the OSCORE group, whose GID was specified
in the 'context_id' parameter of the Token request. in the 'context_id' parameter of the Token request.
4.3.2. Resource Server Side 4.3.2. Resource Server Side
After successful validation of the Access Token as defined in After successful validation of the Access Token as defined in
Section 4.2 and after having sent the 2.01 (Created) response, the RS Section 4.2 and after having sent the 2.01 (Created) response, the RS
can start to communicate with the Client using Group OSCORE can start to communicate with the Client using Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming [I-D.ietf-core-oscore-groupcomm].
request, if Group OSCORE verification succeeds, the verification of
access rights is performed as described in Section 4.4. When processing an incoming request protected with Group OSCORE, the
RS MUST consider as valid public key of the Client only the public
key specified in the stored Access Token. As defined in Section 4.5,
a possible change of public key requires the Client to upload to the
RS a new Access Token bound to the new public key.
Additionally, for every incoming request, if Group OSCORE
verification succeeds, the verification of access rights is performed
as described in Section 4.4.
After the expiration of the Access Token related to a Group OSCORE After the expiration of the Access Token related to a Group OSCORE
Security Context, if the Client uses the Group OSCORE Security Security Context, if the Client uses the Group OSCORE Security
Context to send a request for any resource intended for OSCORE group Context to send a request for any resource intended for OSCORE group
members and that requires an active Access Token, the RS MUST respond members and that requires an active Access Token, the RS MUST respond
with a 4.01 (Unauthorized) error message protected with the Group with a 4.01 (Unauthorized) error message protected with the Group
OSCORE Security Context. OSCORE Security Context.
4.4. Access Rights Verification 4.4. Access Rights Verification
The RS MUST follow the procedures defined in Section 5.8.2 of The RS MUST follow the procedures defined in Section 5.10.2 of
[I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE-
protected request from a Client, the RS processes it according to protected request from a Client, the RS processes it according to
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
If the Group OSCORE verification succeeds, and the target resource If the Group OSCORE verification succeeds, and the target resource
requires authorization, the RS retrieves the authorization requires authorization, the RS retrieves the authorization
information from the Access Token associated to the Group OSCORE information from the Access Token associated to the Group OSCORE
Security Context. Then, the RS MUST verify that the action requested Security Context. Then, the RS MUST verify that the action requested
on the resource is authorized. on the resource is authorized.
The response code MUST be 4.01 (Unauthorized) if the RS has no valid The response code MUST be 4.01 (Unauthorized) if the RS has no valid
Access Token for the Client. If the RS has an Access Token for the Access Token for the Client. If the RS has an Access Token for the
Client but no actions are authorized on the target resource, the RS Client but no actions are authorized on the target resource, the RS
MUST reject the request with a 4.03 (Forbidden). If the RS has an MUST reject the request with a 4.03 (Forbidden). If the RS has an
Access Token for the Client but the requested action is not Access Token for the Client but the requested action is not
authorized, the RS MUST reject the request with a 4.05 (Method Not authorized, the RS MUST reject the request with a 4.05 (Method Not
Allowed). Allowed).
4.5. Change of Client's Public Key in the Group
During its membership in the OSCORE group, the client might change
the public key it uses in the group. When this happens, the Client
uploads the new public key to the Group Manager, as defined in
Section 11 of [I-D.ietf-ace-key-groupcomm-oscore].
After that, and in order to continue communicating with the RS, the
Client MUST perform the following actions.
1. The Client requests a new Access Token to the AS, as defined in
Section 3. In particular, when sending the POST request as
defined in Section 3.1, the Client indicates:
* The current Group Identifier of the OSCORE group, as value of
the 'context_id' parameter.
* The current Sender ID it has in the OSCORE group, as value of
the 'salt_input' parameter.
* The new public key it uses in the OSCORE group, as value of
the 'req_cnf' parameter.
* The proof-of-possession signature corresponding to the new
public key, as value of the 'client_cred_verify' parameter.
2. After receiving the response from the AS (see Section 3.2), the
Client performs the same exchanges with the RS as defined in
Section 4.
When receiving the new Access Token, the RS performs the same steps
defined in Section 4.2, with the following addition, in case the new
Access Token is successfully verified and stored. The RS also
deletes the old Access Token, i.e. the one whose associated 3-tuple
has the same GID and SaltInput values as in the 3-tuple including the
new public key of the Client and associated to the new Access Token.
5. Secure Communication with the AS 5. Secure Communication with the AS
As specified in the ACE framework (Section 5.7 of As specified in the ACE framework (Sections 5.8 and 5.9 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client)
and the AS communicate via the /introspection or /token endpoint. and the AS communicate via the /introspection or /token endpoint.
The use of CoAP and OSCORE for this communication is RECOMMENDED in The use of CoAP and OSCORE [RFC8613] for this communication is
this profile. Other protocols (such as HTTP and DTLS or TLS) MAY be RECOMMENDED in this profile. Other protocols fulfilling the security
used instead. requirements defined in Section 5 of [I-D.ietf-ace-oauth-authz] (such
as HTTP and DTLS or TLS) MAY be used instead.
If OSCORE [RFC8613] is used, the requesting entity and the AS are If OSCORE [RFC8613] is used, the requesting entity and the AS are
expected to have a pre-established Security Context in place. How expected to have a pre-established Security Context in place. How
this Security Context is established is out of the scope of this this Security Context is established is out of the scope of this
profile. Furthermore, the requesting entity and the AS communicate profile. Furthermore, the requesting entity and the AS communicate
using OSCORE through the /introspection endpoint as specified in using OSCORE through the /introspection endpoint as specified in
Section 5.7 of [I-D.ietf-ace-oauth-authz], and through the /token Section 5.9 of [I-D.ietf-ace-oauth-authz], and through the /token
endpoint as specified in Section 5.6 of [I-D.ietf-ace-oauth-authz]. endpoint as specified in Section 5.8 of [I-D.ietf-ace-oauth-authz].
6. Discarding the Security Context 6. Discarding the Security Context
As members of an OSCORE group, the Client and the RS may As members of an OSCORE group, the Client and the RS may
independently leave the group or be forced to, e.g. if compromised or independently leave the group or be forced to, e.g. if compromised or
suspected so. Upon leaving the OSCORE group, the Client or RS also suspected so. Upon leaving the OSCORE group, the Client or RS also
discards the Group OSCORE Security Context, which may anyway be discards the Group OSCORE Security Context, which may anyway be
renewed by the Group Manager through a group rekeying process (see renewed by the Group Manager through a group rekeying process (see
Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). Section 3.1 of [I-D.ietf-core-oscore-groupcomm]).
skipping to change at page 26, line 41 skipping to change at page 28, line 12
o Reference: [[this document]] (Section 3.1) o Reference: [[this document]] (Section 3.1)
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ace-key-groupcomm-oscore] [I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-09 (work in progress), November 2020. oscore-10 (work in progress), February 2021.
[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)", draft-ietf-ace-oauth-authz-37
(work in progress), June 2020. (work in progress), February 2021.
[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-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization "OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-13 (work in progress), October 2020. oscore-profile-16 (work in progress), January 2021.
[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.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", draft-
ietf-core-groupcomm-bis-02 (work in progress), November ietf-core-groupcomm-bis-03 (work in progress), February
2020. 2021.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
"Group OSCORE - Secure Group Communication for CoAP", J. Park, "Group OSCORE - Secure Group Communication for
draft-ietf-core-oscore-groupcomm-10 (work in progress), CoAP", draft-ietf-core-oscore-groupcomm-11 (work in
November 2020. progress), February 2021.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12
(work in progress), September 2020. (work in progress), September 2020.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis- Structures and Process", draft-ietf-cose-rfc8152bis-
struct-14 (work in progress), September 2020. struct-15 (work in progress), February 2021.
[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>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
skipping to change at page 28, line 46 skipping to change at page 30, line 10
[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>.
[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
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-14 (work in progress), October 2020. authorize-15 (work in progress), January 2021.
[I-D.ietf-ace-mqtt-tls-profile] [I-D.ietf-ace-mqtt-tls-profile]
Sengul, C. and A. Kirby, "Message Queuing Telemetry Sengul, C. and A. Kirby, "Message Queuing Telemetry
Transport (MQTT)-TLS profile of Authentication and Transport (MQTT)-TLS profile of Authentication and
Authorization for Constrained Environments (ACE) Authorization for Constrained Environments (ACE)
Framework", draft-ietf-ace-mqtt-tls-profile-08 (work in Framework", draft-ietf-ace-mqtt-tls-profile-10 (work in
progress), November 2020. progress), December 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-41 (work in progress),
2020. February 2021.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca- Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-07 (work in progress), November core-oscore-discovery-08 (work in progress), February
2020. 2021.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Dual Mode (Group OSCORE & OSCORE) Appendix A. Dual Mode (Group OSCORE & OSCORE)
skipping to change at page 31, line 30 skipping to change at page 32, line 44
| (aud: RS1, sid: 0, gid: abcd0000, ...) | | | (aud: RS1, sid: 0, gid: abcd0000, ...) | |
| | | | | | | |
|<--------------------------------- Access Token + RS Information -----| |<--------------------------------- Access Token + RS Information -----|
| | (aud: RS1, sid: 0, gid: abcd0000, ...) | | | (aud: RS1, sid: 0, gid: abcd0000, ...) |
| | | | | | | |
|---- POST /authz-info ------>| | | |---- POST /authz-info ------>| | |
| (access_token, N1, ID1) | | | | (access_token, N1, ID1) | | |
| | | | | | | |
|<-- 2.01 Created (N2, ID2) --| | | |<-- 2.01 Created (N2, ID2) --| | |
| | | | | | | |
/Pairwise OSCORE Sec /Pairwise OSCORE Sec | | /Pairwise Sec /Pairwise Sec | |
Context Derivation/ Context Derivation/ | | Context Derivation/ Context Derivation/ | |
| | | | | | | |
|-------- POST /token ------------------------------------------------>| |-------- POST /token ------------------------------------------------>|
| (aud: RS2, sid: 0, gid: abcd0000, ...) | | | (aud: RS2, sid: 0, gid: abcd0000, ...) | |
| | | | | | | |
|<--------------------------------- Access Token + RS Information -----| |<--------------------------------- Access Token + RS Information -----|
| | (aud: RS2, sid: 0, gid: abcd0000, ...) | | | (aud: RS2, sid: 0, gid: abcd0000, ...) |
| | | | | | | |
|----- POST /authz-info ------------------>| | |----- POST /authz-info ------------------>| |
| (access_token, N1', ID1') | | | | (access_token, N1', ID1') | | |
| | | | | | | |
|<-- 2.01 Created (N2', ID2')--------------| | |<-- 2.01 Created (N2', ID2')--------------| |
| | | | | | | |
/Pairwise OSCORE Sec | /Pairwise OSCORE Sec | /Pairwise Sec | /Pairwise Sec |
Context Derivation/ | Context Derivation/ | Context Derivation/ | Context Derivation/ |
| | | | | | | |
|------ OSCORE Request ------>| | | |------ OSCORE Request ------>| | |
| (kid: ID2) | | | | (kid: ID2) | | |
| | | | | | | |
| /proof-of-possession | | | /Proof-of-possession; | |
| Sec Context storage/ | | | Pairwise Sec Context storage/ | |
| | | | | | | |
|<----- OSCORE Response ------| | | |<----- OSCORE Response ------| | |
| | | | | | | |
/proof-of-possession | | | /Proof-of-possession; | | |
Sec Context storage/ | | | Paiwise Sec Context storage/ | | |
| | | |
/Mutual authentication | | |
between C and RS1 | | |
(as OSCORE peers)/ | | |
| | | |
| | | | | | | |
|-- Group OSCORE Request -+-->| | | |-- Group OSCORE Request -+-->| | |
| (kid: 0, gid: abcd0000) \-------------->| | | (kid: 0, gid: abcd0000) \-------------->| |
| | | | | | | |
|<--- Group OSCORE Response --| | | |<--- Group OSCORE Response --| | |
| (kid: 1) | | | | (kid: 1) | | |
| | | | | | | |
/Mutual authentication | | |
between C and RS1 | | |
(as group members)/ | | |
| | | |
|<--- Group OSCORE Response ---------------| | |<--- Group OSCORE Response ---------------| |
| (kid: 2) | | | | (kid: 2) | | |
| | | |
/Mutual authentication | | |
between C and RS2 | | |
(as group members)/ | | |
| | | |
| ... | | | | ... | | |
Figure 8: Protocol Overview. Figure 8: Protocol Overview.
A.1.1. Pre-Conditions A.1.1. Pre-Conditions
The same pre-conditions for the main mode of this profile (see The same pre-conditions for the main mode of this profile (see
Section 2.1) hold for the dual mode described in this appendix. Section 2.1) hold for the dual mode described in this appendix.
A.1.2. Access Token Posting A.1.2. Access Token Posting
After having retrieved the Access Token from the AS, the Client After having retrieved the Access Token from the AS, the Client
generates a nonce N1 and an identifier ID1 unique in the sets of its generates a nonce N1 and an identifier ID1 unique in the sets of its
own Recipient IDs from its pairwise OSCORE Security Contexts. The own Recipient IDs from its pairwise OSCORE Security Contexts. The
client then posts both the Access Token, N1 and its chosen ID to the client then posts both the Access Token, N1 and its chosen ID to the
RS, using the /authz-info endpoint and mechanisms specified in RS, using the /authz-info endpoint and mechanisms specified in
Section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = Section 5.10 of [I-D.ietf-ace-oauth-authz] and Content-Format =
application/ace+cbor. When using the dual mode of this profile, the application/ace+cbor. When using the dual mode of this profile, the
communication with the authz-info endpoint is not protected, except communication with the authz-info endpoint is not protected, except
for update of access rights. Note that, when using the dual mode, for update of access rights. Note that, when using the dual mode,
this request can alternatively be protected with Group OSCORE, using this request can alternatively be protected with Group OSCORE, using
the Group OSCORE Security Context paired with the pairwise OSCORE the Group OSCORE Security Context paired with the pairwise OSCORE
Security Context originally established with the first Access Token Security Context originally established with the first Access Token
posting. posting.
If the Access Token is valid, the RS replies to this POST request If the Access Token is valid, the RS replies to this POST request
with a 2.01 (Created) response with Content-Format = application/ with a 2.01 (Created) response with Content-Format = application/
skipping to change at page 34, line 14 skipping to change at page 35, line 40
OSCORE group, that the Client knows as a group member, as well as its OSCORE group, that the Client knows as a group member, as well as its
own Sender ID in the OSCORE group. own Sender ID in the OSCORE group.
When the Client communicates with the RS using the pairwise OSCORE When the Client communicates with the RS using the pairwise OSCORE
Security Context, the RS achieves proof-of-possession of the Security Context, the RS achieves proof-of-possession of the
credentials bound to the Access Token. Also, the RS verifies that credentials bound to the Access Token. Also, the RS verifies that
the Client is a legitimate member of the OSCORE group. the Client is a legitimate member of the OSCORE group.
A.1.4. Secure Communication A.1.4. Secure Communication
The Client can send a request protected with OSCORE to the RS. Other than starting the communication with the RS using Group OSCORE
as described in Section 4.3, the Client can send to the RS a request
protected with OSCORE, using the pairwise OSCORE Security Context.
If the request is correctly verified, then the RS stores the pairwise If the request is successfully verified, then the RS stores the
OSCORE Security Context, and uses it to protect the possible pairwise OSCORE Security Context, and uses it to protect the possible
response, as well as further communications with the Client, until response, as well as further communications with the Client, until
the Access Token expires. This pairwise OSCORE Security Context is the Access Token is deleted, due to e.g. expiration. This pairwise
discarded when an Access Token (whether the same or different) is OSCORE Security Context is discarded when an Access Token (whether
used to successfully derive a new pairwise OSCORE Security Context. the same or different) is used to successfully derive a new pairwise
OSCORE Security Context.
As discussed in Section 2 of [I-D.ietf-ace-oscore-profile], the use As discussed in Section 7 of [I-D.ietf-ace-oscore-profile], the use
of random nonces N1 and N2 during the exchange between the Client and of random nonces N1 and N2 during the exchange between the Client and
the RS prevents the reuse of AEAD nonces and keys with different the RS prevents the reuse of AEAD nonces and keys with different
messages including the possibility of two-time pads, in case of re- messages. Reuse might otherwise occur when Client and RS derive a
derivation of the pairwise OSCORE Security Context both for Clients new pairwise OSCORE Security Context from an existing (non-expired)
and Resource Servers from an old non-expired Access Token, e.g. in Access Token, e.g. in case of reboot of either the Client or the RS,
case of reboot of either the Client or the RS. and might lead to loss of both confidentiality and integrity.
Additionally, just as per the main mode of this profile (see Additionally, just as per the main mode of this profile (see
Section 4.3), the Client and RS can also securely communicate by Section 4.3), the Client and RS can also securely communicate by
protecting messages with Group OSCORE, using the Group OSCORE protecting messages with Group OSCORE, using the Group OSCORE
Security Context already established upon joining the OSCORE group. Security Context already established upon joining the OSCORE group.
A.2. Client-AS Communication A.2. Client-AS Communication
This section details the Access Token POST Request that the Client This section details the Access Token POST Request that the Client
sends to the /token endpoint of the AS, as well as the related Access sends to the /token endpoint of the AS, as well as the related Access
skipping to change at page 35, line 7 skipping to change at page 36, line 35
Security Context based on a shared Master Secret and a set of other Security Context based on a shared Master Secret and a set of other
parameters, established between the OSCORE client and server, which parameters, established between the OSCORE client and server, which
the client receives from the AS in this exchange. the client receives from the AS in this exchange.
The proof-of-possession key (pop-key) received from the AS in this The proof-of-possession key (pop-key) received from the AS in this
exchange MUST be used to build the Master Secret in OSCORE (see exchange MUST be used to build the Master Secret in OSCORE (see
Appendix A.3.3 and Appendix A.3.4). Appendix A.3.3 and Appendix A.3.4).
A.2.1. C-to-AS: POST to Token Endpoint A.2.1. C-to-AS: POST to Token Endpoint
The Client-to-AS request is specified in Section 5.6.1 of The Client-to-AS request is specified in Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request
to the /token endpoint over a secure channel that guarantees to the /token endpoint over a secure channel that guarantees
authentication, message integrity and confidentiality. authentication, message integrity and confidentiality.
The POST request is formatted as the analogous Client-to-AS request The POST request is formatted as the analogous Client-to-AS request
in the main mode of this profile (see Section 3.1), with the in the main mode of this profile (see Section 3.1), with the
following modifications. following modifications.
o The parameter 'req_cnf' MUST NOT be included in the payload. o The parameter 'req_cnf' MUST NOT be included in the payload.
skipping to change at page 36, line 49 skipping to change at page 38, line 8
(assigned as discussed in Appendix A.2.2). (assigned as discussed in Appendix A.2.2).
This identifier, together with other information such as audience, This identifier, together with other information such as audience,
can be used by the AS to determine the shared secret bound to the can be used by the AS to determine the shared secret bound to the
proof-of-possession Access Token and therefore MUST identify a proof-of-possession Access Token and therefore MUST identify a
symmetric key that was previously generated by the AS as a shared symmetric key that was previously generated by the AS as a shared
secret for the communication between the Client and the RS. The AS secret for the communication between the Client and the RS. The AS
MUST verify that the received value identifies a proof-of-possession MUST verify that the received value identifies a proof-of-possession
key that has previously been issued to the requesting Client. If key that has previously been issued to the requesting Client. If
that is not the case, the Client-to-AS request MUST be declined with that is not the case, the Client-to-AS request MUST be declined with
the error code 'invalid_request' as defined in Section 5.6.3 of the error code 'invalid_request' as defined in Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
This POST request for updating the rights of an Access Token MUST NOT This POST request for updating the access rights of an Access Token
include the parameters 'salt_input', 'context_id', 'client_cred' and SHOULD NOT include the parameters 'salt_input', 'context_id',
'client_cred_verify'. 'client_cred' and 'client_cred_verify'. An exception is the case
defined in Appendix A.3.6, where the Client, following a change of
public key in the OSCORE group, requests a new Access Token
associated to the new public key, while still without changing the
existing pairwise OSCORE Security Context with the RS.
An example of such a request, with payload in CBOR diagnostic An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in notation without the tag and value abbreviations is reported in
Figure 10. Figure 10.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
skipping to change at page 37, line 32 skipping to change at page 38, line 42
"kid" : h'01' "kid" : h'01'
} }
} }
Figure 10: Example C-to-AS POST /token request for updating rights to Figure 10: Example C-to-AS POST /token request for updating rights to
an Access Token bound to a symmetric key. an Access Token bound to a symmetric key.
A.2.1.1. 'client_cred' Parameter A.2.1.1. 'client_cred' Parameter
The 'client_cred' parameter is an OPTIONAL parameter of the Access The 'client_cred' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of Token request message defined in Section 5.8.1. of
[I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric
key that the Client wishes to use as its own public key, but which is key that the Client wishes to use as its own public key, but which is
not used as proof-of-possession key. not used as proof-of-possession key.
This parameter follows the syntax of the 'cnf' claim from Section 3.1 This parameter follows the syntax of the 'cnf' claim from Section 3.1
of [RFC8747] when including Value Type "COSE_Key" (1) and specifying of [RFC8747] when including Value Type "COSE_Key" (1) and specifying
an asymmetric key. Alternative Value Types defined in future an asymmetric key. Alternative Value Types defined in future
specifications are fine to consider if indicating a non-encrypted specifications are fine to consider if indicating a non-encrypted
asymmetric key. asymmetric key.
skipping to change at page 38, line 6 skipping to change at page 39, line 16
After having verified the POST request to the /token endpoint and After having verified the POST request to the /token endpoint and
that the Client is authorized to obtain an Access Token corresponding that the Client is authorized to obtain an Access Token corresponding
to its Access Token request, the AS MUST verify the signature in the to its Access Token request, the AS MUST verify the signature in the
'client_cred_verify' parameter, by using the public key specified in 'client_cred_verify' parameter, by using the public key specified in
the 'client_cred' parameter. If the verification fails, the AS the 'client_cred' parameter. If the verification fails, the AS
considers the Client request invalid. The AS does not perform this considers the Client request invalid. The AS does not perform this
operation when asked to update a previously released Access Token. operation when asked to update a previously released Access Token.
If all verifications are successful, the AS responds as defined in If all verifications are successful, the AS responds as defined in
Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request
was invalid, or not authorized, the AS returns an error response as was invalid, or not authorized, the AS returns an error response as
described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz].
The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED
for a specific Access Token by including the 'profile' parameter with for a specific Access Token by including the 'profile' parameter with
the value "coap_group_oscore" in the Access Token response. This the value "coap_group_oscore" in the Access Token response. This
means that the Client MUST use OSCORE and/or Group OSCORE towards all means that the Client MUST use OSCORE and/or Group OSCORE towards all
the Resource Servers for which this Access Token is valid. the Resource Servers for which this Access Token is valid.
In particular, the Client MUST follow Appendix A.3.3 to derive the In particular, the Client MUST follow Appendix A.3.3 to derive the
pairwise OSCORE Security Context to use for communications with the pairwise OSCORE Security Context to use for communications with the
RS. Instead, the Client has already established the related Group RS. Instead, the Client has already established the related Group
OSCORE Security Context to communicate with members of the OSCORE OSCORE Security Context to communicate with members of the OSCORE
group, upon previously joining that group. group, upon previously joining that group.
Usually, it is assumed that constrained devices will be pre- Usually, it is assumed that constrained devices will be pre-
configured with the necessary profile, so that this kind of profile configured with the necessary profile, so that this kind of profile
negotiation can be omitted. signaling can be omitted.
In contrast with the main mode of this profile, the Access Token In contrast with the main mode of this profile, the Access Token
response to the Client is analogous to the one in the OSCORE profile response to the Client is analogous to the one in the OSCORE profile
of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile].
In particular, the AS provides an OSCORE_Input_Material object, which In particular, the AS provides an OSCORE_Input_Material object, which
is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and
included in the 'cnf' parameter (see Section 3.2 of included in the 'cnf' parameter (see Section 3.2 of
[I-D.ietf-ace-oauth-params]) of the Access Token response. [I-D.ietf-ace-oauth-params]) of the Access Token response.
The AS MUST send different OSCORE_Input_Material (and therefore The AS MUST send different OSCORE_Input_Material (and therefore
skipping to change at page 39, line 21 skipping to change at page 40, line 33
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Type: "application/ace+cbor" Content-Type: "application/ace+cbor"
Payload: Payload:
{ {
"access_token" : h'8343a1010aa2044c53 ...' "access_token" : h'8343a1010aa2044c53 ...'
(remainder of CWT omitted for brevity), (remainder of CWT omitted for brevity),
"profile" : "coap_group_oscore", "profile" : "coap_group_oscore",
"expires_in" : 3600, "expires_in" : 3600,
"cnf" : { "cnf" : {
"osc" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : AES-CCM-16-64-128,
"id" : h'01', "id" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f', "ms" : h'f9af838368e353e78888e1426bd94e6f',
"salt" : h'1122', "salt" : h'1122',
"contextId" : h'99' "contextId" : h'99'
} }
} }
} }
Figure 11: Example AS-to-C Access Token response with the Group Figure 11: Example AS-to-C Access Token response with the Group
OSCORE profile. OSCORE profile.
Figure 12 shows an example CWT, containing the necessary OSCORE Figure 12 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim, in CBOR diagnostic notation without parameters in the 'cnf' claim, in CBOR diagnostic notation without
tag and value abbreviations. tag and value abbreviations.
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1360189224", "iat" : 1360189224,
"exp" : "1360289224", "exp" : 1360289224,
"scope" : "temperature_g firmware_p", "scope" : "temperature_g firmware_p",
"cnf" : { "cnf" : {
"osc" : { "osc" : {
"alg" : "AES-CCM-16-64-128", "alg" : AES-CCM-16-64-128,
"id" : h'01', "id" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f', "ms" : h'f9af838368e353e78888e1426bd94e6f',
"salt" : h'1122', "salt" : h'1122',
"contextId" : h'99' "contextId" : h'99'
}, },
"salt_input" : h'00', "salt_input" : h'00',
"contextId_input" : h'abcd0000', "contextId_input" : h'abcd0000',
"client_cred" : { "client_cred" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : EC2, "kty" : EC2,
skipping to change at page 41, line 11 skipping to change at page 42, line 11
1A 51145DC8 # unsigned(1360289224) 1A 51145DC8 # unsigned(1360289224)
09 # unsigned(9) 09 # unsigned(9)
78 18 # text(24) 78 18 # text(24)
74656D70657261747572655F67206669726D776172655F70 74656D70657261747572655F67206669726D776172655F70
08 # unsigned(8) 08 # unsigned(8)
A1 # map(1) A1 # map(1)
04 # unsigned(4) 04 # unsigned(4)
A5 # map(5) A5 # map(5)
04 # unsigned(4) 04 # unsigned(4)
0A # unsigned(10) 0A # unsigned(10)
02 # unsigned(2) 00 # unsigned(0)
41 # bytes(1) 41 # bytes(1)
01 # "\x01" 01 # "\x01"
01 # unsigned(1) 02 # unsigned(2)
50 # bytes(16) 50 # bytes(16)
F9AF838368E353E78888E1426BD94E6F F9AF838368E353E78888E1426BD94E6F
05 # unsigned(5) 05 # unsigned(5)
42 # bytes(2) 42 # bytes(2)
1122 # "\x11\"" 1122 # "\x11\""
06 # unsigned(6) 06 # unsigned(6)
41 # bytes(1) 41 # bytes(1)
99 # "\x99" 99 # "\x99"
18 3C # unsigned(60) 18 3C # unsigned(60)
41 # bytes(1) 41 # bytes(1)
skipping to change at page 42, line 39 skipping to change at page 43, line 39
Figure 14: Example AS-to-C Access Token response with the Group Figure 14: Example AS-to-C Access Token response with the Group
OSCORE profile, for update of access rights. OSCORE profile, for update of access rights.
Figure 15 shows an example CWT, containing the necessary OSCORE Figure 15 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations. diagnostic notation without tag and value abbreviations.
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1360189224", "iat" : 1360189224,
"exp" : "1360289224", "exp" : 1360289224,
"scope" : "temperature_h", "scope" : "temperature_h",
"cnf" : { "cnf" : {
"kid" : h'01' "kid" : h'01'
} }
} }
Figure 15: Example CWT with OSCORE parameters for update of access Figure 15: Example CWT with OSCORE parameters for update of access
rights. rights.
A.2.2.1. Public Key Hash as Client Credential A.2.2.1. Public Key Hash as Client Credential
skipping to change at page 45, line 48 skipping to change at page 46, line 48
access rights) to the /authz-info endpoint. access rights) to the /authz-info endpoint.
The Client MUST protect the request using either the pairwise OSCORE The Client MUST protect the request using either the pairwise OSCORE
Security Context established during the first Access Token exchange, Security Context established during the first Access Token exchange,
or the Group OSCORE Security Context associated to that pairwise or the Group OSCORE Security Context associated to that pairwise
OSCORE Security Context. OSCORE Security Context.
In either case, the Client MUST only send the Access Token in the In either case, the Client MUST only send the Access Token in the
payload, i.e. no nonce or identifier are sent. After proper payload, i.e. no nonce or identifier are sent. After proper
verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the
RS will replace the old Access Token with the new one, maintaining new Access Token will supersede the old one at the RS, by replacing
the same pairwise OSCORE Security Context and Group OSCORE Security the corresponding authorization information. At the same time, the
Context. RS will maintain the same pairwise OSCORE Security Context and Group
OSCORE Security Context, as now both associated to the new Access
Token.
A.3.2. RS-to-C: 2.01 (Created) A.3.2. RS-to-C: 2.01 (Created)
The RS MUST verify the validity of the Access Token as defined in The RS MUST verify the validity of the Access Token as defined in
Section 4.2, with the following modifications. Section 4.2, with the following modifications.
o The RS checks that the 'cnf' claim is included in the Access Token o If the POST request to /authz-info is not protected, the RS checks
and that it contains an OSCORE_Input_Material object. that the 'cnf' claim is included in the Access Token and that it
contains an OSCORE_Input_Material object. Also, the RS checks
that the 'salt_input', 'client_cred' and 'contextId_input' claims
are included in the Access Token.
o The RS checks that the 'client_cred' claim is included in the o If the POST request to /authz-info is protected with the pairwise
Access Token. OSCORE Security Context shared with the Client or with the Group
OSCORE Security Context of the OSCORE group, i.e. the Client is
requesting an update of access rights, the RS checks that the
'cnf' claim is included in the Access Token and that it contains
only the 'kid' field.
o The RS considers the content of the 'client_cred' claim as the o If the 'salt_input', 'client_cred' and 'contextId_input' claims
public key associated to the signing private key of the Client in are included in the Access Token, the RS extracts the content of
the OSCORE group, whose GID is specified in the 'contextId_input' 'client_cred'. Then, the RS considers that content as the public
key associated to the signing private key of the Client in the
OSCORE group, whose GID is specified in the 'contextId_input'
claim. The RS can compare this public key with the public key of claim. The RS can compare this public key with the public key of
the claimed Client retrieved from the Group Manager (see the claimed Client retrieved from the Group Manager (see
Section 4.2). Section 4.2).
If any of the checks fails, the RS MUST consider the Access Token non If any of the checks fails, the RS MUST consider the Access Token non
valid, and MUST respond to the Client with an error response code valid, and MUST respond to the Client with an error response code
equivalent to the CoAP code 4.00 (Bad Request). equivalent to the CoAP code 4.00 (Bad Request).
If the Access Token is valid and further checks on its content are If the Access Token is valid and further checks on its content are
successful, the RS MUST generate a nonce N2, an OSCORE Recipient ID successful, the RS proceeds as follows.
(ID2), and include them in the 2.01 (Created) response to the Client,
as defined in Section 4.2 of the OSCORE profile of ACE In case the POST request to /authz-info was not protected, the RS
MUST generate a nonce N2, an OSCORE Recipient ID (ID2), and include
them in the 2.01 (Created) response to the Client, as defined in
Section 4.2 of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
Instead, in case the POST request to /authz-info was protected, the
RS MUST ignore any nonce and identifiers in the request, if any was
sent. Then, the RS MUST check that the 'kid' field of the 'cnf'
claim in the new Access Token matches the identifier of the OSCORE
Input Material of a pairwise OSCORE Security Context such that:
o The pairwise OSCORE Security Context was used to protect the
request, if this was protected with OSCORE; or
o The pairwise OSCORE Security Context is bound to the Group OSCORE
Security Context used to protect the request, if this was
protected with Group OSCORE.
If either verification is successful, the new Access Token supersedes
the old one at the RS. Besides, the RS associates the new Access
Token to the same pairwise OSCORE Security Context identified above,
as also bound to a Group OSCORE Security Context. The RS MUST
respond with a 2.01 (Created) response with no payload, protected
with the same Security Context used to protect the request. In
particular, no new pairwise OSCORE Security Context is established
between the Client and the RS. If any verification fails, the RS
MUST respond with a 4.01 (Unauthorized) error response.
Further recommendations, considerations and behaviors defined in Further recommendations, considerations and behaviors defined in
Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this
specification. specification.
A.3.3. OSCORE Setup - Client Side A.3.3. OSCORE Setup - Client Side
Once having received the 2.01 (Created) response from the RS, Once having received the 2.01 (Created) response from the RS,
following the POST request to the authz-info endpoint, the Client following an unprotected POST request to the /authz-info endpoint,
MUST extract the nonce N2 from the 'nonce2' parameter, and the Client the Client MUST extract the nonce N2 from the 'nonce2' parameter, and
identifier from the 'ace_server_recipientid' parameter in the CBOR the Client identifier from the 'ace_server_recipientid' parameter in
map of the response payload. Note that this identifier is used by C the CBOR map of the response payload. Note that this identifier is
as Sender ID in the pairwise OSCORE Security Context to be used by C as Sender ID in the pairwise OSCORE Security Context to be
established with the RS, and is different as well as unrelated to the established with the RS, and is different as well as unrelated to the
Sender ID of C in the OSCORE group. Sender ID of C in the OSCORE group.
Then, the Client performs the following actions, in order to set up Then, the Client performs the following actions, in order to set up
and fully derive the pairwise OSCORE Security Context for and fully derive the pairwise OSCORE Security Context for
communicating with the RS. communicating with the RS.
o The Client MUST set the ID Context of the pairwise OSCORE Security o The Client MUST set the ID Context of the pairwise OSCORE Security
Context as the concatenation of: i) GID, i.e. the Group Identifier Context as the concatenation of: i) GID, i.e. the Group Identifier
of the OSCORE group, as specified by the Client in the of the OSCORE group, as specified by the Client in the
skipping to change at page 48, line 37 skipping to change at page 50, line 26
Context following Section 3.2.1 of [RFC8613]. Context following Section 3.2.1 of [RFC8613].
From then on, when communicating with the RS to access the resources From then on, when communicating with the RS to access the resources
as specified by the authorization information, the Client MUST use as specified by the authorization information, the Client MUST use
the newly established pairwise OSCORE Security Context or the Group the newly established pairwise OSCORE Security Context or the Group
OSCORE Security Context of the OSCORE Group where both the Client and OSCORE Security Context of the OSCORE Group where both the Client and
the RS are members. the RS are members.
If any of the expected parameters is missing (e.g., any of the If any of the expected parameters is missing (e.g., any of the
mandatory parameters from the AS or the RS), or if mandatory parameters from the AS or the RS), or if
ace_client_recipientid equals ace_server_recipientid, then the client ace_client_recipientid equals ace_server_recipientid (and as a
MUST stop the exchange, and MUST NOT derive the pairwise OSCORE consequence the Sender and Recipient Keys derived would be equal, see
Security Context. The Client MAY restart the exchange, to get the Section 3.3 of [RFC8613]), then the client MUST stop the exchange,
correct security material. and MUST NOT derive the pairwise OSCORE Security Context. The Client
MAY restart the exchange, to get the correct security input material.
The Client can use this pairwise OSCORE Security Context to send The Client can use this pairwise OSCORE Security Context to send
requests to the RS protected with OSCORE. Besides, the Client can requests to the RS protected with OSCORE. Besides, the Client can
use the Group OSCORE Security Context for protecting unicast requests use the Group OSCORE Security Context for protecting unicast requests
to the RS, or multicast requests to the OSCORE group including also to the RS, or multicast requests to the OSCORE group including also
the RS. the RS. Mutual authentication as group members is only achieved
after the client has successfully verified the Group OSCORE protected
response from the RS. Similarly, mutual authentication as OSCORE
peers is only achieved after the client has successfully verified the
OSCORE protected response from the RS, using the pairwise OSCORE
Security Context.
Note that the ID Context of the pairwise OSCORE Security Context can Note that the ID Context of the pairwise OSCORE Security Context can
be assigned by the AS, communicated and set in both the RS and Client be assigned by the AS, communicated and set in both the RS and Client
after the exchange specified in this profile is executed. after the exchange specified in this profile is executed.
Subsequently, the Client and RS can update their ID Context by Subsequently, the Client and RS can update their ID Context by
running a mechanism such as the one defined in Appendix B.2 of running a mechanism such as the one defined in Appendix B.2 of
[RFC8613] if they both support it and are configured to do so. In [RFC8613] if they both support it and are configured to do so. In
that case, the ID Context in the pairwise OSCORE Security Context that case, the ID Context in the pairwise OSCORE Security Context
will not match the "contextId" parameter of the corresponding will not match the "contextId" parameter of the corresponding
OSCORE_Input_Material. Running the procedure in Appendix B.2 of OSCORE_Input_Material. Running the procedure in Appendix B.2 of
[RFC8613] results in the keying material in the pairwise OSCORE [RFC8613] results in the keying material in the pairwise OSCORE
Security Contexts of the Client and RS being updated. The Client can Security Contexts of the Client and RS being updated. The Client can
achieve the same result by re-posting the Access Token as described achieve the same result by re-posting the Access Token to the
in Section 4.1 of [I-D.ietf-ace-oscore-profile], although without unprotected /authz-info endpoint at the RS, as described in
Section 4.1 of [I-D.ietf-ace-oscore-profile], although without
updating the ID Context. updating the ID Context.
A.3.4. OSCORE Setup - Resource Server Side A.3.4. OSCORE Setup - Resource Server Side
After validation of the Access Token as defined in Appendix A.3.2 and After validation of the Access Token as defined in Appendix A.3.2 and
after sending the 2.01 (Created) response, the RS performs the after sending the 2.01 (Created) response to an unprotected POST
following actions, in order to set up and fully derive the pairwise request to the /authz-info endpoint, the RS performs the following
OSCORE Security Context created to communicate with the Client. actions, in order to set up and fully derive the pairwise OSCORE
Security Context created to communicate with the Client.
o The RS MUST set the ID Context of the pairwise OSCORE Security o The RS MUST set the ID Context of the pairwise OSCORE Security
Context as the concatenation of: i) GID, i.e. the Group Identifier Context as the concatenation of: i) GID, i.e. the Group Identifier
of the OSCORE group, as specified in the 'contextId' parameter of of the OSCORE group, as specified in the 'contextId' parameter of
the OSCORE_Input_Material, in the 'cnf' claim of the Access Token the OSCORE_Input_Material, in the 'cnf' claim of the Access Token
received from the Client (see Appendix A.3.1); ii) the nonce N1; received from the Client (see Appendix A.3.1); ii) the nonce N1;
iii) the nonce N2; and iv) CID which is the value in the contextId iii) the nonce N2; and iv) CID which is the value in the contextId
parameter of the OSCORE_Input_Material provided in the 'cnf' claim parameter of the OSCORE_Input_Material provided in the 'cnf' claim
of the Access Token. The concatenation occurs in this order: ID of the Access Token. The concatenation occurs in this order: ID
Context = GID | N1 | N2 | CID, where | denotes byte string Context = GID | N1 | N2 | CID, where | denotes byte string
skipping to change at page 50, line 37 skipping to change at page 52, line 34
authorization information from the Access Token with the just authorization information from the Access Token with the just
established pairwise OSCORE Security Context. Furthermore, as established pairwise OSCORE Security Context. Furthermore, as
defined in Section 4.2, the RS MUST associate the authorization defined in Section 4.2, the RS MUST associate the authorization
information from the Access Token with the Group OSCORE Security information from the Access Token with the Group OSCORE Security
Context. Context.
Then, the RS uses this pairwise OSCORE Security Context to verify Then, the RS uses this pairwise OSCORE Security Context to verify
requests from and send responses to the Client protected with OSCORE, requests from and send responses to the Client protected with OSCORE,
when this Security Context is used. If OSCORE verification fails, when this Security Context is used. If OSCORE verification fails,
error responses are used, as specified in Section 8 of [RFC8613]. error responses are used, as specified in Section 8 of [RFC8613].
Besides, the RS uses the Group OSCORE Security Context to verify Besides, the RS uses the Group OSCORE Security Context to verify
(multicast) requests from and send responses to the Client protected (multicast) requests from and send responses to the Client protected
with Group OSCORE. If Group OSCORE verification fails, error with Group OSCORE. When processing an incoming request protected
responses are used, as specified in Section 8 and Section 9 of with Group OSCORE, the RS MUST consider as valid public key of the
Client only the public key specified in the stored Access Token. As
defined in Appendix A.3.6, a change of public key in the group
requires the Client to upload to the RS a new Access Token,
specifying the new public key in the 'client_cred' claim.
If Group OSCORE verification fails, error responses are used, as
specified in Section 8 and Section 9 of
[I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming
request, if OSCORE or Group OSCORE verification succeeds, the request, if OSCORE or Group OSCORE verification succeeds, the
verification of access rights is performed as described in verification of access rights is performed as described in
Appendix A.3.5. Appendix A.3.5.
After the expiration of the Access Token related to a pairwise OSCORE After the deletion of the Access Token related to a pairwise OSCORE
Security Context and to a Group OSCORE Security Context, the RS MUST Security Context and to a Group OSCORE Security Context, due to e.g.
NOT use the pairwise OSCORE Security Context and MUST respond with an expiration, the RS MUST NOT use the pairwise OSCORE Security Context.
unprotected 4.01 (Unauthorized) error message to received requests The RS MUST respond with an unprotected 4.01 (Unauthorized) error
that correspond to a security context with an expired Access Token. message to received requests that correspond to a pairwise OSCORE
Also, if the Client uses the Group OSCORE Security Context to send a Security Context with a deleted Access Token. Also, if the Client
request for any resource intended for OSCORE group members and that uses the Group OSCORE Security Context to send a request for any
requires an active Access Token, the RS MUST respond with a 4.01 resource intended for OSCORE group members and that requires an
(Unauthorized) error message protected with the Group OSCORE Security active Access Token, the RS MUST respond with a 4.01 (Unauthorized)
Context. error message protected with the Group OSCORE Security Context.
The same considerations, related to the value of the ID Context The same considerations, related to the value of the ID Context
changing, as in Appendix A.3.3 hold also for the RS. changing, as in Appendix A.3.3 hold also for the RS.
A.3.5. Access Rights Verification A.3.5. Access Rights Verification
The RS MUST follow the procedures defined in Section 4.4. The RS MUST follow the procedures defined in Section 4.4.
Additionally, if the RS receives an OSCORE-protected request from a Additionally, if the RS receives an OSCORE-protected request from a
Client, the RS processes it according to [RFC8613]. Client, the RS processes it according to [RFC8613].
If the OSCORE verification succeeds, and the target resource requires If the OSCORE verification succeeds, and the target resource requires
authorization, the RS retrieves the authorization information from authorization, the RS retrieves the authorization information from
the Access Token associated to the pairwise OSCORE Security Context the Access Token associated to the pairwise OSCORE Security Context
and to the Group OSCORE Security Context. Then, the RS MUST verify and to the Group OSCORE Security Context. Then, the RS MUST verify
that the action requested on the resource is authorized. that the action requested on the resource is authorized.
The response code MUST be 4.01 (Unauthorized) if the RS has no valid The response code MUST be 4.01 (Unauthorized) if the RS has no valid
Access Token for the Client. Access Token for the Client.
A.3.6. Change of Client's Public Key in the Group
During its membership in the OSCORE group, the client might change
the public key it uses in the group. When this happens, the Client
uploads the new public key to the Group Manager, as defined in
Section 11 of [I-D.ietf-ace-key-groupcomm-oscore].
After that, the Client may still have an Access Token previously
uploaded to the RS, which is not expired yet and still valid to the
best of the Client's knowledge. Then, in order to continue
communicating with the RS, the Client MUST perform the following
actions.
1. The Client requests a new Access Token to the AS, as defined in
Appendix A.2.1 for the update of access rights, i.e. with the
'req_cnf' parameter including only a 'kid' field. In particular,
when sending the POST request to the AS, the Client indicates:
* The current Group Identifier of the OSCORE group, as value of
the 'context_id' parameter.
* The current Sender ID it has in the OSCORE group, as value of
the 'salt_input' parameter.
* The new public key it has in the OSCORE group, as value of the
'client_cred' parameter.
* The proof-of-possession signature corresponding to the new
public key, as value of the 'client_cred_verify' parameter.
* The same current or instead new set of access rights, as value
of the 'scope' parameter.
2. After receiving the response from the AS (see Appendix A.2.2),
the Client performs the same exchanges with the RS as defined in
Appendix A.3, with the following difference: the POST request to
/authz-info for uploading the new Access Token MUST be protected
with the pairwise OSCORE Security Context shared with the RS.
When receiving the new Access Token, the RS performs the same steps
defined in Appendix A.3.2. In particular, no new pairwise OSCORE
Security Context is established between the Client and the RS.
A.4. Secure Communication with the AS A.4. Secure Communication with the AS
The same considerations for secure communication with the AS as The same considerations for secure communication with the AS as
defined in Section 5 hold. defined in Section 5 hold.
A.5. Discarding the Security Context A.5. Discarding the Security Context
The Client and the RS MUST follow what is defined in Section 6 of The Client and the RS MUST follow what is defined in Section 6 of
[I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE
Security Context. Security Context.
 End of changes. 89 change blocks. 
193 lines changed or deleted 378 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/