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/ |