ACE Working Group M. Tiloca
Internet-Draft R. Hoeglund
Intended status: Standards Track RISE AB
Expires: September 10, 2020 L. Seitz
Combitech
F. Palombini
Ericsson AB
March 09, 2020
Group OSCORE Profile of the Authentication and Authorization for
Constrained Environments Framework
draft-tiloca-ace-group-oscore-profile-02
Abstract
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. The
profile uses Group OSCORE to provide communication security between a
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
public key of the Client associated to the signing private key used
in the OSCORE group. The profile uses Group OSCORE to achieve server
authentication, as well as proof-of-possession for the Client public
key. Also, it provides proof of Client's membership to the correct
OSCORE group, by binding the Access Token to information from the
Group OSCORE Security Context, thus allowing the Resource Server(s)
to verify the Client's membership upon receiving a message protected
with Group OSCORE from the Client.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Tiloca, et al. Expires September 10, 2020 [Page 1]
Internet-Draft Group OSCORE Profile of ACE March 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 8
2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 8
2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 9
2.4. Secure Communication . . . . . . . . . . . . . . . . . . 9
3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 10
3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 10
3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 12
3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 12
3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 12
3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 13
3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 16
3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 16
4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16
4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 17
4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 17
4.3. Client-RS Secure Communication . . . . . . . . . . . . . 18
4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 18
4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 18
4.4. Access Rights Verification . . . . . . . . . . . . . . . 19
5. Secure Communication with the AS . . . . . . . . . . . . . . 19
6. Discarding the Security Context . . . . . . . . . . . . . . . 19
7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 21
10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 22
10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 23
Tiloca, et al. Expires September 10, 2020 [Page 2]
Internet-Draft Group OSCORE Profile of ACE March 2020
10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 23
10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 28
A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 29
A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 31
A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 31
A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 31
A.1.4. Secure Communication . . . . . . . . . . . . . . . . 32
A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 33
A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 33
A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 36
A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 43
A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 44
A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 44
A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 45
A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 47
A.3.5. Access Rights Verification . . . . . . . . . . . . . 49
A.4. Secure Communication with the AS . . . . . . . . . . . . 49
A.5. Discarding the Security Context . . . . . . . . . . . . . 50
A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 50
A.7. Security Considerations . . . . . . . . . . . . . . . . . 50
A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 51
Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction
A number of applications rely on a group communication model, where a
Client can access a resource shared by multiple Resource Servers at
once, e.g. over IP multicast. Typical examples are switching of
luminaries, actuators control, and distribution of software updates.
Secure communication in the group can be achieved by sharing a set of
key material, which is typically provided upon joining the group.
For some instances of such applications, it may be just fine to
enforce access control in a straightforward and plain fashion. That
is, it is assumed that any Client authorized to join the group and to
get the group key material, is also implicitly authorized as a group
member to perform any action at any resource of any Server in the
group. An example of an application where such implicit
authorization might be used is a lighting scenario, where the
lightbulbs are the Servers, while the user account on an app on the
user's phone is the Client. In this case, it might be fine to not
require additional authorization evidence from any user account, if
Tiloca, et al. Expires September 10, 2020 [Page 3]
Internet-Draft Group OSCORE Profile of ACE March 2020
it is acceptable that any current group member is also authorized to
switch on and off any light, or to check their status.
However, in different instances of such applications, the approach
above is not desirable, as different group members are intended to
have different access rights to resources of other group members.
For instance, a more fine-grained authorization approach is required
in the two following use cases.
As a first case, an application provides control of smart locks
acting as Servers in the group, where: a first type of Client, e.g. a
user account of a child, is allowed to only query the status of the
smart locks; while a second type of Client, e.g. a user account of a
parent, is allowed to both query and change the status of the smart
locks. Further similar applications concern the enforcement of
different sets of permissions in groups with sensor/actuator devices,
e.g. thermostats, acting as Servers. Also, some group members may
even be intended as Servers only. Hence, they must be prevented from
acting as Clients altogether and from accessing resources at other
Servers, especially when attempting to perform non-safe operations.
As a second case, building automation scenarios often rely on Servers
that, under different circumstances, enforce different level of
priority for processing received commands. For instance, BACnet
deployments consider multiple classes of Clients, e.g. a normal light
switch (C1) and an emergency fire panel (C2). Then, a C1 Client is
not allowed to override a command from a C2 Client, until the latter
relinquishes control at its higher priority. That is: i) only C2
Clients should be able to adjust the minimum required level of
priority on the Servers, so rightly locking out C1 Clients if needed;
and ii) when a Server is set to accept only high-priority commands,
only C2 Clients should be able to perform such commands otherwise
allowed also to C1 Clients. Given the different maximum authority of
different Clients, fine-grained access control would effectively
limit the execution of high- and emergency-priority commands only to
devices that are in fact authorized to do so. Besides, it would
prevent a misconfigured or compromised device from initiating a high-
priority command and lock out normal control.
Hence, in the cases discussed above, being a legitimate group member
and having obtained the group key material is not supposed to imply
any particular access rights. Also, introducing a different security
group for each different set of access rights would result in
additional key material to distribute and manage. In particular, if
the access rights for a single node change, this would require to
evict that node from the current group, followed by that node joining
a different group aligned with its new access rights. Moreover, the
key material of both groups would have to be renewed for their
Tiloca, et al. Expires September 10, 2020 [Page 4]
Internet-Draft Group OSCORE Profile of ACE March 2020
current members. Overall, this would have a non negligible impact on
operations and performance in the system.
A fine-grained access control model can be rather enforced within a
same group, by using the Authentication and Authorization for
Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz].
That is, a Client has to first obtain authorization credentials in
the form of an Access Token, and post it to the Resource Server(s) in
the group before accessing the intended resources.
The ACE framework delegates to separate profile documents how to
secure communications between the Client and the Resource Server.
However each of the current profiles of ACE defined in
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize]
[I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol
that cannot be used to protect group messages sent over IP multicast.
This document specifies a profile of ACE, where a Client uses CoAP
[RFC7252] or CoAP over IP multicast [I-D.dijk-core-groupcomm-bis] to
communicate to one or multiple Resource Servers, which are members of
an application group and share a common set of resources. This
profile uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the
security protocol to protect messages exchanged between the Client a
the Resource Servers. Hence, it requires that both the Client and
the Resource Servers have previously joined the same OSCORE group.
That is, this profile describes how access control is enforced for a
Client after it has joined an OSCORE group, to access resources at
other members in that group. The process for joining the OSCORE
group through the respective Group Manager as defined in
[I-D.ietf-ace-key-groupcomm-oscore] takes place before the process
described in this document, and is out of the scope of this profile.
The Client authorizes its access to the Resource Server by using an
Access Token, which is bound to a key (the proof-of-possession key).
This profile uses Group OSCORE to achieve server authentication, as
well as proof-of-possession for the Client public key associated to
the signing private key used in an OSCORE group. Furthermore, this
profile provides proof of Client's membership to the correct OSCORE
group, by binding the Access Token to the Client public key and
information from the pre-established Group OSCORE Security Context,
thus allowing the Resource Server to verify this upon reception of a
messages protected with Group OSCORE from the Client.
OSCORE [RFC8613] specifies how to use COSE [RFC8152] to secure CoAP
messages. Group OSCORE builds on OSCORE to provide secure group
communication, and ensures source authentication by means of digital
countersignatures embedded in protected messages.
Tiloca, et al. Expires September 10, 2020 [Page 5]
Internet-Draft Group OSCORE Profile of ACE March 2020
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol [RFC7252], as well as related to the
protection and processing of CoAP messages in OSCORE [RFC8613] and
Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These include the
concept of Group Manager, as the entity responsible for a set of
groups where communications among members are secured with Group
OSCORE.
Readers are expected to be familiar with the terms and concepts
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-oscore-profile]. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. In
particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS).
Note that, unless otherwise indicated, the term "endpoint" is used
here following its OAuth definition, aimed at denoting resources such
as /token and /introspect at the AS, and /authz-info at the RS. This
document does not use the CoAP definition of "endpoint", which is "An
entity participating in the CoAP protocol".
2. Protocol Overview
This section provides an overview of this profile, i.e. on how to use
the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz] to secure communications between a Client
and a (set of) Resource Server(s) using Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
Note that this profile of ACE describes how access control can be
enforced for a node after it has joined an OSCORE group, to access
resources at other members in that group.
In particular, the process for joining the OSCORE group through the
respective Group Manager as defined in
[I-D.ietf-ace-key-groupcomm-oscore] must take place before the
process described in this document, and is out of the scope of this
profile.
Tiloca, et al. Expires September 10, 2020 [Page 6]
Internet-Draft Group OSCORE Profile of ACE March 2020
An overview of the protocol flow for this profile is shown in
Figure 1. In the figure, it is assumed that both RS1 and RS2 are
associated with the same AS. It is also assumed that C, RS1 and RS2
have previously joined an OSCORE group with Group Identifier (gid)
"abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the
group, respectively.
C RS1 RS2 AS
| [--- Resource Request --->] | | |
| | | |
| [<--- AS Information -----] | | |
| | | |
|-------- POST /token -------------------------------------------------->|
| (aud: RS1, sid: 0, gid: abcd0000, ... ) | |
| | | |
|<---------------------------------- Access Token + RS Information ------|
| | (aud: RS1, sid: 0, gid: abcd0000, ... ) |
|---- POST /authz-info ------>| | |
| (access_token) | | |
| | | |
|<--- 2.01 Created ------| | |
| | | |
|-------- POST /token -------------------------------------------------->|
| (aud: RS2, sid: 0, gid: abcd0000, ... ) | |
| | | |
|<---------------------------------- Access Token + RS Information ------|
| | (aud: RS2, sid: 0, gid: abcd0000, ... ) |
| | | |
|----- POST /authz-info ------------------->| |
| (access_token) | | |
| | | |
|<--- 2.01 Created -------------------| |
| | | |
|-- Group OSCORE Request --+-->| | |
| (kid: 0, gid: abcd0000) \--------------->| |
| | | |
|<--- Group OSCORE Response ---| | |
| (kid: 1) | | |
| | | |
|<--- Group OSCORE Response ----------------| |
| (kid: 2) | | |
| ... | | |
Figure 1: Protocol Overview.
Tiloca, et al. Expires September 10, 2020 [Page 7]
Internet-Draft Group OSCORE Profile of ACE March 2020
2.1. Pre-Conditions
Using Group OSCORE and this profile requires both the Client and the
Resource Servers to have previously joined an OSCORE group. This
especially includes the derivation of the Group OSCORE Security
Context and the assignment of unique Sender IDs to use in the group.
Nodes may join the OSCORE group through the respective Group Manager
by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore],
which is also based on ACE.
After the Client and Resource Servers have joined the group, this
profile provides access control for accessing resources on those
Resource Servers, by securely communicating with Group OSCORE.
As a pre-requisite for this profile, the Client has to have
successfully joined the OSCORE group where also the Resource Servers
(RSs) are members. Depending on the limited information initially
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
the approach defined in [I-D.tiloca-core-oscore-discovery].
2.2. Access Token Retrieval
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,
using the /token endpoint, as specified in Section 5.6 of
[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
are members of a same OSCORE group.
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. The AS MUST specify these pieces of information in the Access
Token, included in the Access Token response to the Client.
Furthermore, in the Access Token request to the AS, the Client MUST
also include: its own public key, associated to the private signing
key used in the OSCORE group; and a signature computed with such
private key, over a quantity uniquely related to the secure
communication association between the Client and the AS. The AS MUST
include also the public key indicated by the client in the Access
Token.
To gain knowledge of the AS in charge of a resource hosted at a RS,
the Client MAY first send an initial Unauthorized Resource Request
message to that RS. Then, the RS denies the request and replies to
the Client by specifying the address of its AS, as defined in
Section 5.1 of [I-D.ietf-ace-oauth-authz]. The Access Token request
Tiloca, et al. Expires September 10, 2020 [Page 8]
Internet-Draft Group OSCORE Profile of ACE March 2020
and response MUST be confidentiality-protected and ensure
authenticity. This profile RECOMMENDS the use of OSCORE between the
Client and the AS, but TLS [RFC5246][RFC8446] or DTLS
[RFC6347][I-D.ietf-tls-dtls13] MAY be used additionally or instead.
2.3. Access Token Posting
After having retrieved the Access Token from the AS, the Client posts
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] and
Content-Format = application/ace+cbor.
If the Access Token is valid, the RS replies to this POST request
with a 2.01 (Created) response with Content-Format = application/
ace+cbor. Also, the RS associates the received Access Token with the
Group OSCORE Security Context identified by the Group Identifier
specified in the Access Token, following Section 3.2 of [RFC8613].
In practice, the RS maintains a collection of Security Contexts with
associated authorization information, for all the clients that it is
currently communicating with, and the authorization information is a
policy used as input when processing requests from those clients.
Finally, the RS stores the association between i) the authorization
information from the Access Token; and ii) the Group Identifier of
the OSCORE group together with the Sender ID and the public key of
the Client in that group. This binds the Access Token with the Group
OSCORE Security Context of the OSCORE group.
Finally, when the Client communicates with the RS using the Group
OSCORE Security Context, the RS verifies that the Client is a
legitimate member of the OSCORE group and especially the exact group
member with the same Sender ID associated to the Access Token. This
occurs when verifying a request protected with Group OSCORE, since it
embeds a countersignature computed also over the Client's Sender ID
included in the message.
2.4. Secure Communication
The Client can send a request protected with Group OSCORE
[I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast
request addressed to the RS, or a multicast request addressed to the
OSCORE group where the RS is also a member. To this end, the Client
uses the Group OSCORE Security Context already established upon
joining the OSCORE group, e.g. by using the approach defined in
[I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back
to the Client, protecting it by means of the same Group OSCORE
Security Context.
Tiloca, et al. Expires September 10, 2020 [Page 9]
Internet-Draft Group OSCORE Profile of ACE March 2020
3. Client-AS Communication
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
Token response.
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.
3.1. C-to-AS: POST to Token Endpoint
The Client-to-AS request is specified in Section 5.6.1 of
[I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request
to the /token endpoint over a secure channel that guarantees
authentication, message integrity and confidentiality.
The POST request is formatted as the analogous Client-to-AS request
in the OSCORE profile of ACE (see Section 3.1 of
[I-D.ietf-ace-oscore-profile]), with the following additional
parameters that MUST be included in the payload.
o 'context_id', defined in Section 3.1.1 of this specification.
This parameter specifies the Group Identifier (GID), i.e. the Id
Context of an OSCORE group where the Client and the RS are
currently members. In particular, the Client wishes to
communicate with the RS using the Group OSCORE Security Context
associated to that OSCORE group.
o 'salt_input', defined in Section 3.1.2 of this specification.
This parameter includes the Sender ID that the Client has in the
OSCORE group whose GID is specified in the 'context_id' parameter
above.
o 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params].
This parameter includes the public key associated to the signing
private key that the Client uses in the OSCORE group whose GID is
specified in the 'context_id' parameter above. This public key
will be used as the pop-key bound to the Access Token.
o 'client_cred_verify', defined in Section 3.1.3 of this
specification. This parameter includes a signature computed by
the Client, by using the private key associated to the public key
in the 'req_cnf' parameter above. This allows the AS to verify
that the Client indeed owns the private key associated to that
public key, as its alleged identity credential within the OSCORE
group. The information to be signed MUST be the byte
representation of a quantity that uniquely represents the secure
communication association between the Client and the AS. It is
Tiloca, et al. Expires September 10, 2020 [Page 10]
Internet-Draft Group OSCORE Profile of ACE March 2020
RECOMMENDED that the Client considers the following as information
to sign.
* If the Client and the AS communicate over (D)TLS, the
information to sign is an exporter value computed as defined in
Section 7.5 of [RFC8446]. In particular, the exporter label
MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in
Section 10.5 of this specification, together with an empty
'context_value', and 32 bytes as 'key_length'.
* If the Client and the AS communicate over OSCORE, the
information to sign is the output PRK of a HKDF-Extract step
[RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In particular,
'salt' takes (x1 | x2), where x1 is the ID Context of the
OSCORE Security Context between the Client and the AS, x2 is
the Sender ID of the Client in that Context, and | denotes byte
string concatenation. Also, 'IKM' is the OSCORE Master Secret
of the OSCORE Security Context between the Client and the AS.
The HKDF MUST be one of the HMAC-based HKDF [RFC5869]
algorithms defined for COSE [RFC8152]. HKDF SHA-256 is
mandatory to implement.
An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in
Figure 2.
Tiloca, et al. Expires September 10, 2020 [Page 11]
Internet-Draft Group OSCORE Profile of ACE March 2020
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: "application/ace+cbor"
Payload:
{
"audience" : "tempSensor4711",
"scope" : "read",
"context_id" : h'abcd0000',
"salt_input" : h'00',
"req_cnf" : {
"COSE_Key" : {
"kty" : EC2,
"crv" : P-256,
"x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
27c9e354089bbe13',
"y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
731e79a3b4e47120'
}
},
"client_cred_verify" : h'...'
(signature content omitted for brevity),
}
Figure 2: Example C-to-AS POST /token request for an Access Token
bound to an asymmetric key.
3.1.1. 'context_id' Parameter
The 'context_id' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of
[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.
Its exact content is profile specific.
3.1.2. 'salt_input' Parameter
The 'salt_input' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of
[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
cryptographic key material. Its exact content is profile specific.
3.1.3. 'client_cred_verify' Parameter
The 'client_cred_verify' parameter is an OPTIONAL parameter of the
Access Token request message defined in Section 5.6.1. of
[I-D.ietf-ace-oauth-authz]. This parameter provides a signature
Tiloca, et al. Expires September 10, 2020 [Page 12]
Internet-Draft Group OSCORE Profile of ACE March 2020
computed by the Client to prove the possession of its own private
key.
3.2. AS-to-C: Access Token
After having verified the POST request to the /token endpoint and
that the Client is authorized to obtain an Access Token corresponding
to its Access Token request, the AS MUST verify the signature in the
'client_cred_verify' parameter, by using the public key specified in
the 'req_cnf' parameter. If the verification fails, the AS considers
the Client request invalid.
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
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].
The AS can signal that the use of Group OSCORE is REQUIRED for a
specific Access Token by including the 'profile' parameter with the
value "coap_group_oscore" in the Access Token response. The Client
MUST use Group OSCORE towards all the Resource Servers for which this
Access Token is valid. Usually, it is assumed that constrained
devices will be pre-configured with the necessary profile, so that
this kind of profile negotiation can be omitted.
The AS MUST include the following information as metadata of the
issued Access Token. This profile RECOMMENDS the use of CBOR web
tokens (CWT) as specified in [RFC8392]. The Access Token MUST be
encrypted, since it will be transferred from the Client to the RS
over an unprotected channel.
o The same parameter 'profile' included in the Token Response to the
Client.
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
'salt_input' parameter MUST be placed in the 'salt_input' claim of
the Access Token, defined in Section 3.2.1 of this specification.
o The Context Id input specified in the 'context_id' parameter of
the Token Request. If the Access Token is a CWT, the content of
the 'context_id' parameter MUST be placed in the 'contextId_input'
claim of the Access Token, defined in Section 3.2.2 of this
specification.
o The public key that the client uses in the OSCORE group and
specified in the 'req_cnf' parameter of the Token request. If the
Access Token is a CWT, the public key MUST be specified in the
Tiloca, et al. Expires September 10, 2020 [Page 13]
Internet-Draft Group OSCORE Profile of ACE March 2020
'cnf' claim, which follows the syntax from Section 3.1 of
[I-D.ietf-ace-cwt-proof-of-possession] when including Value Type
"COSE_Key" (1) and specifying an asymmetric key. Alternative
Value Types defined in future specifications are fine to consider
if indicating a non-encrypted asymmetric key.
Figure 3 shows an example of such an AS response, with payload in
CBOR diagnostic notation without the tag and value abbreviations.
Header: Created (Code=2.01)
Content-Type: "application/ace+cbor"
Payload:
{
"access_token" : h'a5037674656d7053656e73 ...'
(remainder of CWT omitted for brevity),
"profile" : "coap_group_oscore",
"expires_in" : 3600,
}
Figure 3: Example AS-to-C Access Token response with the Group OSCORE
profile.
Figure 4 shows an example CWT, containing the client's public key in
the group (as pop-key) in the 'cnf' claim, in CBOR diagnostic
notation without tag and value abbreviations.
{
"aud" : "tempSensorInLivingRoom",
"iat" : "1360189224",
"exp" : "1360289224",
"scope" : "temperature_g firmware_p",
"cnf" : {
"COSE_Key" : {
"kty" : EC2,
"crv" : P-256,
"x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
27c9e354089bbe13',
"y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
731e79a3b4e47120'
},
"salt_input" : h'00',
"contextId_input" : h'abcd0000'
}
Figure 4: Example CWT with OSCORE parameters (CBOR diagnostic
notation).
Tiloca, et al. Expires September 10, 2020 [Page 14]
Internet-Draft Group OSCORE Profile of ACE March 2020
The same CWT as in Figure 4 and encoded in CBOR is shown in Figure 5,
using the value abbreviations defined in [I-D.ietf-ace-oauth-authz]
and [I-D.ietf-ace-cwt-proof-of-possession].
NOTE: it should be checked (and in case fixed) that the values used
below (which are not yet registered) are the final values registered
in IANA.
A7 # map(7)
03 # unsigned(3)
76 # text(22)
74656D7053656E736F72496E4C6976696E67526F6F6D
06 # unsigned(6)
1A 5112D728 # unsigned(1360189224)
04 # unsigned(4)
1A 51145DC8 # unsigned(1360289224)
09 # unsigned(9)
78 18 # text(24)
74656D70657261747572655F67206669726D776172655F70
08 # unsigned(8)
A1 # map(1)
01 # unsigned(1)
A4 # map(4)
01 # unsigned(1)
02 # unsigned(2)
20 # negative(0)
01 # unsigned(1)
21 # negative(1)
58 20 # bytes(32)
D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9
E354089BBE13
22 # negative(2)
58 20 # bytes(32)
F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E
79A3B4E47120
18 3C # unsigned(60)
41 # bytes(1)
00
18 3D # unsigned(61)
44 # bytes(4)
ABCD0000
Figure 5: Example CWT with OSCORE parameters.
Tiloca, et al. Expires September 10, 2020 [Page 15]
Internet-Draft Group OSCORE Profile of ACE March 2020
3.2.1. Salt Input Claim
The 'salt_input' claim provides a value that the Client requesting
the Access Token wishes to use as a part of a salt with the RS, e.g.
for deriving cryptographic material.
This parameter specifies the value of the salt input, encoded as a
CBOR byte string.
3.2.2. Context ID Input Claim
The 'contextId_input' claim provides a value that the Client
requesting the Access Token wishes to use with the RS, as a hint for
a security context.
This parameter specifies the value of the context ID input, encoded
as a CBOR byte string.
4. Client-RS Communication
This section details the POST request and response to the /authz-info
endpoint between the Client and the RS.
The proof-of-possession required to bind the Access Token to the
Client is explicitly performed when the RS receives a message
protected with Group OSCORE from the Client. In particular, the RS
verifies the countersignature embedded in the message by using the
Client's public key bound to the Access Token, hence also
authenticating the Client. Similarly, when receiving a protected
response message from the RS, the Client verifies the
countersignature embedded in the message by using the RS's public
key, hence authenticating the RS.
Therefore, an attacker using a stolen Access Token cannot generate a
valid Group OSCORE message signed with the Client's private key, and
thus cannot prove possession of the pop-key bound to the Access
Token. Also, if a Client legitimately owns an Access Token but has
not joined the OSCORE group, it cannot generate a valid Group OSCORE
message, as it does not own the necessary key material shared among
the group members.
Furthermore, a Client C1 is supposed to obtain a valid Access Token
from the AS, as including the public key associated to its own
signing key used in the OSCORE group, together with its own Sender ID
in that OSCORE group (see Section 3.1). This makes it possible for
the RS receiving an Access Token to verify with the Group Manager of
that OSCORE group whether such a Client has indeed that Sender ID and
that public key in the OSCORE group.
Tiloca, et al. Expires September 10, 2020 [Page 16]
Internet-Draft Group OSCORE Profile of ACE March 2020
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
Access Token, specifying the Sender ID of C1 and a different (made-
up) public key; ii) successfully posting the Access Token to RS; and
then iii) attempting to communicate using Group OSCORE impersonating
C1, while blaming C1 for the consequences.
4.1. C-to-RS POST to authz-info Endpoint
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].
4.2. RS-to-C: 2.01 (Created)
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
additions.
o The RS checks that the 'salt_input' claim is included in the
Access Token.
o The RS checks that the 'contextId_input' claim is included in the
Access Token.
o The RS checks that the 'cnf' claim is included in the Access
Token.
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
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
in [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
retrieved from the Group Manager matches the one retrieved from
the 'cnf' claim. When doing so, the 'kid' parameter of the
COSE_Key, if present, MUST NOT be considered for the comparison.
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
response code equivalent to the CoAP code 4.00 (Bad Request).
If the Access Token is valid and further checks on its content are
successful, the RS associates the authorization information from the
Access Token with the Group OSCORE Security Context.
Tiloca, et al. Expires September 10, 2020 [Page 17]
Internet-Draft Group OSCORE Profile of ACE March 2020
In particular, the RS associates the authorization information from
the Access Token with the tuple (GID, SaltInput, PubKey), where GID
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
that OSCORE group, respectively. These can be retrieved from the
'contextId_input', 'salt_input' and 'cnf' claims of the Access Token,
respectively. The RS MUST keep this association up-to-date over
time.
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].
4.3. Client-RS Secure Communication
When previously joining the OSCORE group, both the Client and RS have
already established the related Group OSCORE Security Context to
communicate as group members. Therefore, they can simply start to
securely communicate using Group OSCORE, without deriving any
additional key material or security association.
4.3.1. Client Side
After having received the 2.01 (Created) response from the RS,
following the POST request to the authz-info endpoint, the Client can
start to communicate with the RS using Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
When communicating with the RS to access the resources as specified
by the authorization information, the Client MUST use the Group
OSCORE Security Context of the OSCORE group, whose GID was specified
in the 'context_id' parameter of the Token request.
4.3.2. Resource Server Side
After successful validation of the Access Token as defined in
Section 4.2 and after having sent the 2.01 (Created) response, the RS
can start to communicate with the Client using Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. 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
Security Context, if the Client uses the Group OSCORE Security
Context to send a request for any resource intended for OSCORE group
members and that requires an active Access Token, the RS MUST respond
with a 4.01 (Unauthorized) error message protected with the Group
OSCORE Security Context.
Tiloca, et al. Expires September 10, 2020 [Page 18]
Internet-Draft Group OSCORE Profile of ACE March 2020
4.4. Access Rights Verification
The RS MUST follow the procedures defined in Section 5.8.2 of
[I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE-
protected request from a Client, the RS processes it according to
[I-D.ietf-core-oscore-groupcomm].
If the Group OSCORE verification succeeds, and the target resource
requires authorization, the RS retrieves the authorization
information from the Access Token associated to the Group OSCORE
Security Context. Then, the RS MUST verify that the action requested
on the resource is authorized.
The response code MUST be 4.01 (Unauthorized) in case the Client has
not used the Group OSCORE Security Context associated with the Access
Token, or if the RS has no valid 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 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 authorized, the RS MUST reject the request
with a 4.05 (Method Not Allowed).
5. Secure Communication with the AS
As specified in the ACE framework (Section 5.7 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client)
and the AS communicate via the /introspection or /token endpoint.
The use of CoAP and OSCORE for this communication is RECOMMENDED in
this profile. Other protocols (such as HTTP and DTLS or TLS) MAY be
used instead.
If OSCORE is used, the requesting entity and the AS are expected to
have pre-established security contexts in place. How these security
contexts are established is out of the scope of this profile.
Furthermore the requesting entity and the AS communicate using OSCORE
([RFC8613]) through the /introspection endpoint as specified in
Section 5.7 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].
6. Discarding the Security Context
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
suspected so. Upon leaving the OSCORE group, the Client or RS also
discards the Group OSCORE Security Context, which may anyway be
renewed by the Group Manager through a group rekeying process (see
Section 2.4 of [I-D.ietf-core-oscore-groupcomm]).
Tiloca, et al. Expires September 10, 2020 [Page 19]
Internet-Draft Group OSCORE Profile of ACE March 2020
The Client or RS can acquire a new Group OSCORE Security Context, by
re-joining the OSCORE group, e.g. by using the approach defined in
[I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client
SHOULD request a new Access Token and post it to the RS.
7. CBOR Mappings
The new parameters defined in this document MUST be mapped to CBOR
types as specified in Figure 6, using the given integer abbreviation
for the map key.
/--------------------+----------+------------\
| Parameter name | CBOR Key | Value Type |
|--------------------+----------+------------|
| context_id | TBD1 | bstr |
| salt_input | TBD2 | bstr |
| client_cred_verify | TBD3 | bstr |
\--------------------+----------+------------/
Figure 6: CBOR mappings for new parameters.
The new claims defined in this document MUST be mapped to CBOR types
as specified in Figure 7, using the given integer abbreviation for
the map key.
/-----------------+----------+------------\
| Claim name | CBOR Key | Value Type |
|-----------------+----------+------------|
| salt_input | TBD4 | bstr |
| contextId_input | TBD5 | bstr |
\-----------------+----------+------------/
Figure 7: CBOR mappings for new claims.
8. Security Considerations
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Thus the general security considerations
from the ACE framework also apply to this profile.
This specification inherits the general security considerations about
Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use
of Group OSCORE according to this profile.
Group OSCORE is designed to secure point-to-point as well as point-
to-multipoint communications, providing a secure binding between a
single request and multiple corresponding responses. In particular,
Tiloca, et al. Expires September 10, 2020 [Page 20]
Internet-Draft Group OSCORE Profile of ACE March 2020
Group OSCORE fulfills the same security requirements of OSCORE, for
group requests and responses. To ensure source authentication of
messages, Group OSCORE uses digital countersignatures that group
members embed in their own transmitted messages.
9. Privacy Considerations
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations
from the ACE framework also apply to this profile.
As this profile uses Group OSCORE, the privacy considerations from
[I-D.ietf-core-oscore-groupcomm] apply to this document as well.
An unprotected response to an unauthorized request may disclose
information about the RS and/or its existing relationship with the
Client. It is advisable to include as little information as possible
in an unencrypted response. However, since both the Client and the
RS share a Group OSCORE Security Context, unauthorized, yet protected
requests are followed by protected responses, which can thus include
more detailed information.
Although encrypted, the Access Token is sent in the clear to the
/authz-info endpoint at the RS. Thus, if the Client uses the same
single Access Token from multiple locations with multiple Resource
Servers, it can risk being tracked through the Access Token's value.
Note that, even though communications are protected with Group
OSCORE, some information might still leak, due to the observable
size, source address and destination address of exchanged messages.
10. IANA Considerations
This document has the following actions for IANA.
10.1. ACE Profile Registry
IANA is asked to enter the following value into the "ACE Profile"
Registry defined in Section 8.7 of [I-D.ietf-ace-oauth-authz].
o Profile name: coap_group_oscore
o Profile Description: Profile to secure communications between
constrained nodes using the Authentication and Authorization for
Constrained Environments framework, by enabling authentication and
fine-grained authorization of members of an OSCORE group, that use
a pre-established Group OSCORE Security Context to communicate
Tiloca, et al. Expires September 10, 2020 [Page 21]
Internet-Draft Group OSCORE Profile of ACE March 2020
with Group OSCORE. Optionally, the dual mode defined in
Appendix A additionally establishes a Pairwise OSCORE Security
Context, and thus also enables OSCORE communication between two
members of the OSCORE group.
o Profile ID: TBD (value between 1 and 255)
o Change Controller: IESG
o Specification Document(s): [[this document]]
10.2. OAuth Parameters Registry
IANA is asked to enter the following values into the "OAuth
Parameters" Registry defined in Section 11.2 of [RFC6749].
o Name: "context_id"
o Parameter Usage Location: token request
o Change Controller: IESG
o Reference: Section 3.1.1 of [[this document]]
o Name: "salt_input"
o Parameter Usage Location: token request
o Change Controller: IESG
o Reference: Section 3.1.2 of [[this document]]
o Name: "client_cred_verify"
o Parameter Usage Location: token request
o Change Controller: IESG
o Reference: Section 3.1.3 of [[this document]]
o Name: "client_cred"
o Parameter Usage Location: token request
o Change Controller: IESG
Tiloca, et al. Expires September 10, 2020 [Page 22]
Internet-Draft Group OSCORE Profile of ACE March 2020
o Reference: Appendix A.2.1.1 of [[this document]]
10.3. OAuth Parameters CBOR Mappings Registry
IANA is asked to enter the following values into the "OAuth
Parameters CBOR Mappings" Registry defined in Section 8.9 of
[I-D.ietf-ace-oauth-authz].
o Name: "context_id"
o CBOR Key: TBD1
o Change Controller: IESG
o Reference: Section 3.1.1 of [[this document]]
o Name: "salt_input"
o CBOR Key: TBD2
o Change Controller: IESG
o Reference: Section 3.1.2 of [[this document]]
o Name: "client_cred_verify"
o CBOR Key: TBD3
o Change Controller: IESG
o Reference: Section 3.1.3 of [[this document]]
o Name: "client_cred"
o CBOR Key: TBD6
o Change Controller: IESG
o Reference: Appendix A.2.1.1 of [[this document]]
10.4. CBOR Web Token Claims Registry
IANA is asked to enter the following values into the "CBOR Web Token
Claims" Registry defined in Section 9.1 of [RFC8392].
Tiloca, et al. Expires September 10, 2020 [Page 23]
Internet-Draft Group OSCORE Profile of ACE March 2020
o Claim Name: "salt_input"
o Claim Description: Client provided salt input
o JWT Claim Name: "N/A"
o Claim Key: TBD4
o Claim Value Type(s): bstr
o Change Controller: IESG
o Specification Document(s): Section 3.2.1 of [[this document]]
o Claim Name: "contextId_input"
o Claim Description: Client context id input
o JWT Claim Name: "N/A"
o Claim Key: TBD5
o Claim Value Type(s): bstr
o Change Controller: IESG
o Specification Document(s): Section 3.2.2 of [[this document]]
o Claim Name: "client_cred"
o Claim Description: Client Credential
o JWT Claim Name: "N/A"
o Claim Key: TBD7
o Claim Value Type(s): map
o Change Controller: IESG
o Specification Document(s): Appendix A.2.2.2 of [[this document]]
Tiloca, et al. Expires September 10, 2020 [Page 24]
Internet-Draft Group OSCORE Profile of ACE March 2020
10.5. TLS Exporter Label Registry
IANA is asked to register the following entry in the "TLS Exporter
Label" Registry defined in Section 6 of [RFC5705] and updated in
Section 12 of [RFC8447].
o Value: EXPORTER-ACE-Sign-Challenge-Client-AS
o DTLS-OK: Y
o Recommended: N
o Reference: [[this document]] (Section 3.1)
11. References
11.1. Normative References
[I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-03 (work in progress), March
2020.
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019.
[I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-05 (work in progress), March 2020.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), February 2020.
[I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-12 (work in progress), February 2020.
Tiloca, et al. Expires September 10, 2020 [Page 25]
Internet-Draft Group OSCORE Profile of ACE March 2020
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-10 (work in progress), March 2020.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-07 (work in progress),
March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Tiloca, et al. Expires September 10, 2020 [Page 26]
Internet-Draft Group OSCORE Profile of ACE March 2020
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
11.2. Informative References
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-09 (work in progress), December 2019.
[I-D.ietf-ace-mqtt-tls-profile]
Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
of ACE", draft-ietf-ace-mqtt-tls-profile-04 (work in
progress), March 2020.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-37 (work in progress),
March 2020.
[I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-05 (work in progress), March
2020.
Tiloca, et al. Expires September 10, 2020 [Page 27]
Internet-Draft Group OSCORE Profile of ACE March 2020
[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
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Dual Mode (Group OSCORE & OSCORE)
This appendix defines the dual mode of this profile, which allows
using both OSCORE [RFC8613] and Group OSCORE
[I-D.ietf-core-oscore-groupcomm] as security protocols, by still
relying on a single Access Token.
That is, the dual mode of this profile specifies how a Client uses
CoAP [RFC7252] to communicate to a single Resource Server, or CoAP
over IP multicast [I-D.dijk-core-groupcomm-bis] to communicate to
multiple Resource Servers that are members of a group and share a
common set of resources.
In particular, the dual mode of this profile uses two complementary
security protocols to provide secure communication between the Client
and the Resource Server(s). That is, it defines the use of either
OSCORE or Group OSCORE to protect unicast requests addressed to a
single Resource Server, as well as possible responses. Additionally,
it defines the use of Group OSCORE to protect multicast requests sent
to a group of Resource Servers, as well as possible individual
responses. As for the main mode of this profile, the Client and the
Resource Servers need to have already joined an OSCORE group, for
instance by using the approach defined in
[I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE.
The Client authorizes its access to the Resource Server by using an
Access Token, which is bound to a key (the proof-of-possession key).
This profile mode uses OSCORE to achieve proof of possession, and
OSCORE or Group OSCORE to achieve server authentication.
Unlike in the main mode of this profile, where a public key is used
as pop-key, this dual mode uses OSCORE-related, symmetric key
material as pop-key instead. Furthermore, this dual mode provides
proof of Client's membership to the correct OSCORE group, by securely
binding the pre-established Group OSCORE Security Context to the
Tiloca, et al. Expires September 10, 2020 [Page 28]
Internet-Draft Group OSCORE Profile of ACE March 2020
pairwise OSCORE Security Context newly established between the Client
and the Resource Server.
In addition to the terminology used for the main mode of this
profile, the rest of this appendix refers also to "pairwise OSCORE
Security Context" as to an OSCORE Security Context established
between only one Client and one Resource Server, and used to
communicate with OSCORE [RFC8613].
A.1. Protocol Overview
This section provides an overview on how to use the ACE framework for
authentication and authorization [I-D.ietf-ace-oauth-authz] to secure
communications between a Client and a (set of) Resource Server(s)
using OSCORE [RFC8613] and/or Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
Just as for main mode of this profile overviewed in Section 2, the
process for joining the OSCORE group through the respective Group
Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take
place before the process described in the rest of this section, and
is out of the scope of this profile.
An overview of the protocol flow for the dual mode of this profile is
shown in Figure 8. In the figure, it is assumed that both RS1 and
RS2 are associated with the same AS. It is also assumed that C, RS1
and RS2 have previously joined an OSCORE group with Group Identifier
(gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2"
in the group, respectively.
Tiloca, et al. Expires September 10, 2020 [Page 29]
Internet-Draft Group OSCORE Profile of ACE March 2020
C RS1 RS2 AS
| [--- Resource Request --->] | | |
| | | |
| [<--- AS Information -----] | | |
| | | |
|-------- POST /token -------------------------------------------------->|
| (aud: RS1, sid: 0, gid: abcd0000, ... ) | |
| | | |
|<---------------------------------- Access Token + RS Information ------|
| | (aud: RS1, sid: 0, gid: abcd0000, ... ) |
|---- POST /authz-info ------>| | |
| (access_token, N1) | | |
| | | |
|<--- 2.01 Created (N2) ------| | |
| | | |
/Pairwise OSCORE Sec /Pairwise OSCORE Sec | |
Context Derivation/ Context Derivation/ | |
| | | |
|-------- POST /token -------------------------------------------------->|
| (aud: RS2, sid: 0, gid: abcd0000, ... ) | |
| | | |
|<---------------------------------- Access Token + RS Information ------|
| | (aud: RS2, sid: 0, gid: abcd0000, ... ) |
| | | |
|----- POST /authz-info ------------------->| |
| (access_token, N1') | | |
| | | |
|<--- 2.01 Created (N2') -------------------| |
| | | |
/Pairwise OSCORE Sec | /Pairwise OSCORE Sec |
Context Derivation/ | Context Derivation/ |
| | | |
|------ OSCORE Request ------->| | |
| ?(abcd0000, N1, N2) | | |
| | | |
|<----- OSCORE Response -------| | |
| | | |
|-- Group OSCORE Request --+-->| | |
| (kid: 0, gid: abcd0000) \--------------->| |
| | | |
|<--- Group OSCORE Response ---| | |
| (kid: 1) | | |
| | | |
|<--- Group OSCORE Response ----------------| |
| (kid: 2) | | |
| ... | | |
Figure 8: Protocol Overview.
Tiloca, et al. Expires September 10, 2020 [Page 30]
Internet-Draft Group OSCORE Profile of ACE March 2020
A.1.1. Pre-Conditions
The same pre-conditions for the main mode of this profile (see
Section 2.1) hold for the dual mode described in this appendix.
A.1.2. Access Token Posting
After having retrieved the Access Token from the AS, the Client
generates a nonce N1 and posts both the Access Token and N1 to the
RS, using the /authz-info endpoint and mechanisms specified in
Section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format =
application/ace+cbor.
If the Access Token is valid, the RS replies to this POST request
with a 2.01 (Created) response with Content-Format = application/
ace+cbor, which contains a nonce N2 in a CBOR map.
A.1.3. Setup of the Pairwise OSCORE Security Context
After sending the 2.01 (Created) response, the RS sets the ID Context
of the pairwise OSCORE Security Context (see Section 3 of [RFC8613])
to the Group Identifier of the OSCORE group specified in the Access
Token, concatenated with N1, concatenated with N2, concatenated with
the value in the contextId parameter of the OSCORE_Security_Context
object provided in the 'cnf' claim of the Access Token.
Then, the RS derives the complete pairwise OSCORE Security Context
associated with the received Access Token, following Section 3.2 of
[RFC8613]. In practice, the RS maintains a collection of Security
Contexts with associated authorization information, for all the
clients that it is currently communicating with, and the
authorization information is a policy used as input when processing
requests from those clients.
During the derivation process, the RS uses the ID Context above, the
nonces N1 and N2, and the parameters in the Access Token. The
derivation process uses also the Master Secret of the OSCORE group,
that the RS knows as a group member, as well as the Sender ID of the
Client in the OSCORE group, which is specified in the Access Token.
This ensures that the pairwise OSCORE Security Context is securely
bound to the Group OSCORE Security Context of the OSCORE group.
Finally, the RS stores the association between i) the authorization
information from the Access Token; and ii) the Group Identifier of
the OSCORE group together with the Sender ID and the public key of
the Client in that group.
Tiloca, et al. Expires September 10, 2020 [Page 31]
Internet-Draft Group OSCORE Profile of ACE March 2020
After having received the nonce N2, the Client sets the ID Context in
its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to
the Group Identifier of the OSCORE group concatenated with N1
concatenated with N2, concatenated with the value in the contextId
parameter of the OSCORE_Security_Context object provided in the 'cnf'
parameter of the Access Token response from the AS. Then, the Client
derives the complete pairwise OSCORE Security Context, following
Section 3.2 of [RFC8613]. During the derivation process, the Client
uses the ID Context above, the nonces N1 and N2, plus the parameters
received from the AS. The derivation process uses also the Master
Secret of the OSCORE group, that the Client knows as a group member,
as well as its own Sender ID in the OSCORE group.
When the Client communicates with the RS using the pairwise OSCORE
Security Context, the RS achieves proof-of-possession of the
credentials bound to the Access Token. Also, the RS verifies that
the Client is a legitimate member of the OSCORE group.
A.1.4. Secure Communication
The Client can send a request protected with OSCORE to the RS. This
message may contain the ID Context value of the pairwise OSCORE
Context, whose generation is described in Appendix A.1.3.
If the request is correctly verified, then the RS stores the pairwise
OSCORE Security Context, and uses it to protect the possible
response, as well as further communications with the Client, until
the Access Token expires. This pairwise OSCORE Security Context is
discarded if the same Access Token is re-used to successfully derive
a new pairwise OSCORE Security Context. Once the Client has received
a valid secure response, it does not continue to include the ID
Context value in following requests.
As discussed in Section 2 of [I-D.ietf-ace-oscore-profile], the use
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
messages, in case of re-derivation of the pairwise OSCORE Security
Context both for Clients and Resource Servers from an old non-expired
Access Token, e.g. in case of reboot of either the Client or the RS.
Additionally, just as per the main mode of this profile (see
Section 4.3), the Client and RS can also securely communicate by
protecting messages with Group OSCORE, using the Group OSCORE
Security Context already established upon joining the OSCORE group.
Tiloca, et al. Expires September 10, 2020 [Page 32]
Internet-Draft Group OSCORE Profile of ACE March 2020
A.2. Client-AS Communication
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
Token response.
Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE
Security Context based on a shared Master Secret and a set of other
parameters, established between the OSCORE client and server.
The Client receives these pieces of information from the AS during
the exchange described in this section. In particular, the proof-of-
possession key (pop-key) provisioned by the AS MUST be used to build
the Master Secret in OSCORE (see Appendix A.3.3 and Appendix A.3.4).
A.2.1. C-to-AS: POST to Token Endpoint
The Client-to-AS request is specified in Section 5.6.1 of
[I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request
to the /token endpoint over a secure channel that guarantees
authentication, message integrity and confidentiality.
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
following modifications.
o The parameter 'req_cnf' MUST NOT be included in the payload.
o The parameter 'client_cred', defined in Appendix A.2.1.1 of this
specification, MUST be included in the payload. This parameter
includes the public key associated to the signing private key that
the Client uses in the OSCORE group, whose identifier is indicated
in the 'context_id' parameter.
o The signature included in the parameter 'client_cred_verify' is
computed by using the private key associated to the public key in
the 'client_cred' parameter above.
An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in
Figure 9.
Tiloca, et al. Expires September 10, 2020 [Page 33]
Internet-Draft Group OSCORE Profile of ACE March 2020
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: "application/ace+cbor"
Payload:
{
"audience" : "tempSensor4711",
"scope" : "read",
"context_id" : h'abcd0000',
"salt_input" : h'00',
"client_cred" : {
"COSE_Key" : {
"kty" : EC2,
"crv" : P-256,
"x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
27c9e354089bbe13',
"y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
731e79a3b4e47120'
}
},
"client_cred_verify" : h'...'
(signature content omitted for brevity),
}
Figure 9: Example C-to-AS POST /token request for an Access Token
bound to a symmetric key.
Later on, the Client may want to update its current access rights,
without changing the existing pairwise OSCORE Security Context with
the RS. In this case, the Client MUST include in its POST request to
the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of
[I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as
defined in Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession].
The 'kid' field has as value a CBOR byte string encoding a CBOR
array, which includes:
o As first element, the value of the 'clientId' parameter in the
OSCORE_Security_Context object specified in the 'cnf' parameter,
in the original AS-to-C Access Token response (see
Appendix A.2.2).
o Optionally, as second element, the value of the 'contextId'
parameter in the OSCORE_Security_Context object specified in the
'cnf' parameter, in the original AS-to-C Access Token response
(see Appendix A.2.2).
The CBOR array is defined in Figure 10, and follows the notation of
[RFC8610].
Tiloca, et al. Expires September 10, 2020 [Page 34]
Internet-Draft Group OSCORE Profile of ACE March 2020
These identifiers, together with other information such as audience,
can be used by the AS to determine the shared secret bound to the
proof-of-possession Access Token, and therefore MUST identify a
symmetric key that was previously generated by the AS as a shared
secret for the communication between the Client and the RS. The AS
MUST verify that the received value identifies a proof-of-possession
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
the error code 'invalid_request' as defined in Section 5.6.3 of
[I-D.ietf-ace-oauth-authz].
This POST request for updating the rights of an Access Token MUST NOT
include the parameters 'salt_input', 'context_id', 'client_cred' and
'client_cred_verify'.
kid_arr = [
clientId,
?IdContext
]
kid = bstr .cbor kid_arr
Figure 10: CDDL Notation of kid for Update of Access Rights
An example of such a request, with payload in CBOR diagnostic
notation without the tag and value abbreviations is reported in
Figure 11. In particular: '<< X >>' denotes a CBOR byte string with
string value X; "myclient" stands for the value of the 'clientId'
parameter mentioned above; and "contextid" stands for the value of
the 'contextId' parameter mentioned above.
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: "application/ace+cbor"
Payload:
{
"audience" : "tempSensor4711",
"scope" : "read",
"req_cnf" : {
"kid" : << ["myclient","contextid"] >>
}
}
Figure 11: Example C-to-AS POST /token request for updating rights to
an Access Token bound to a symmetric key.
Tiloca, et al. Expires September 10, 2020 [Page 35]
Internet-Draft Group OSCORE Profile of ACE March 2020
A.2.1.1. 'client_cred' Parameter
The 'client_cred' parameter is an OPTIONAL parameter of the Access
Token request message defined in Section 5.6.1. of
[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
not used as proof-of-possession key.
This parameter follows the syntax of the 'cnf' claim from Section 3.1
of [I-D.ietf-ace-cwt-proof-of-possession] when including Value Type
"COSE_Key" (1) and specifying an asymmetric key. Alternative Value
Types defined in future specifications are fine to consider if
indicating a non-encrypted asymmetric key.
A.2.2. AS-to-C: Access Token
After having verified the POST request to the /token endpoint and
that the Client is authorized to obtain an Access Token corresponding
to its Access Token request, the AS MUST verify the signature in the
'client_cred_verify' parameter, by using the public key specified in
the 'client_cred' parameter. If the verification fails, the AS
considers the Client request invalid. The AS does not perform this
operation when asked to update a previously released Access Token.
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
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].
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
the value "coap_group_oscore" in the Access Token response. This
means that the Client MUST use OSCORE and/or Group OSCORE towards all
the Resource Servers for which this Access Token is valid.
In particular, the Client MUST follow Appendix A.3.3 to derive the
pairwise OSCORE Security Context to use for communications with the
RS. Instead, the Client has already established the related Group
OSCORE Security Context to communicate with members of the OSCORE
group, upon previously joining that group.
Usually, it is assumed that constrained devices will be pre-
configured with the necessary profile, so that this kind of profile
negotiation can be omitted.
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
of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile].
Tiloca, et al. Expires September 10, 2020 [Page 36]
Internet-Draft Group OSCORE Profile of ACE March 2020
In particular, the AS provides an OSCORE_Security_Context object,
which 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
[I-D.ietf-ace-oauth-params]) of the Access Token response.
In the issued Access Token, the AS MUST include as metadata the same
information as defined in the main mode of this profile (see
Section 3.2) with the following modifications.
o The public key that the client uses in the OSCORE group and
specified in the 'client_cred' parameter of the Token request (see
Appendix A.2.1) MUST also be included in the Access Token. If the
Access Token is a CWT, the AS MUST include it in the 'client_cred'
claim of the Access Token, defined in Appendix A.2.2.2 of this
specification.
o The OSCORE_Security_Context object specified in the 'cnf'
parameter of the Access Token response MUST also be included in
the Access Token. If the Access Token is a CWT, the same
OSCORE_Security_Context object included in the 'cnf' parameter of
the Access Token response MUST be included in the 'osc' field (see
Section 9.3 of [I-D.ietf-ace-oscore-profile]) of the 'cnf' claim
of the Access Token.
Figure 12 shows an example of such an AS response, with payload in
CBOR diagnostic notation without the tag and value abbreviations.
Tiloca, et al. Expires September 10, 2020 [Page 37]
Internet-Draft Group OSCORE Profile of ACE March 2020
Header: Created (Code=2.01)
Content-Type: "application/ace+cbor"
Payload:
{
"access_token" : h'a5037674656d7053656e73 ...'
(remainder of CWT omitted for brevity),
"profile" : "coap_group_oscore",
"expires_in" : 3600,
"cnf" : {
"osc" : {
"alg" : "AES-CCM-16-64-128",
"clientId" : h'a8',
"serverId" : h'42',
"ms" : h'f9af838368e353e78888e1426bd94e6f',
"salt" : h'1122',
"contextId" : h'99'
}
}
}
Figure 12: Example AS-to-C Access Token response with the Group
OSCORE profile.
Figure 13 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim, in CBOR diagnostic notation without
tag and value abbreviations.
Tiloca, et al. Expires September 10, 2020 [Page 38]
Internet-Draft Group OSCORE Profile of ACE March 2020
{
"aud" : "tempSensorInLivingRoom",
"iat" : "1360189224",
"exp" : "1360289224",
"scope" : "temperature_g firmware_p",
"cnf" : {
"osc" : {
"alg" : "AES-CCM-16-64-128",
"clientId" : h'00',
"serverId" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f',
"salt" : h'1122',
"contextId" : h'99'
},
"salt_input" : h'00',
"contextId_input" : h'abcd0000',
"client_cred" : {
"COSE_Key" : {
"kty" : EC2,
"crv" : P-256,
"x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
27c9e354089bbe13',
"y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
731e79a3b4e47120'
}
}
}
Figure 13: Example CWT with OSCORE parameters (CBOR diagnostic
notation).
The same CWT as in Figure 13 and encoded in CBOR is shown in
Figure 14, using the value abbreviations defined in
[I-D.ietf-ace-oauth-authz] and
[I-D.ietf-ace-cwt-proof-of-possession], and with 12 as value
abbreviation for the 'client_cred' claim.
NOTE: it should be checked (and in case fixed) that the values used
below (which are not yet registered) are the final values registered
in IANA.
A8 # map(8)
03 # unsigned(3)
76 # text(22)
74656D7053656E736F72496E4C6976696E67526F6F6D
06 # unsigned(6)
1A 5112D728 # unsigned(1360189224)
04 # unsigned(4)
Tiloca, et al. Expires September 10, 2020 [Page 39]
Internet-Draft Group OSCORE Profile of ACE March 2020
1A 51145DC8 # unsigned(1360289224)
09 # unsigned(9)
78 18 # text(24)
74656D70657261747572655F67206669726D776172655F70
08 # unsigned(8)
A1 # map(1)
04 # unsigned(4)
A6 # map(6)
05 # unsigned(5)
0A # unsigned(10)
02 # unsigned(2)
41 # bytes(1)
00
03 # unsigned(3)
41 # bytes(1)
01
01 # unsigned(1)
50 # bytes(16)
F9AF838368E353E78888E1426BD94E6F
06 # unsigned(6)
42 # bytes(2)
1122
07 # unsigned(7)
41 # bytes(1)
99
18 3C # unsigned(60)
41 # bytes(1)
00
18 3D # unsigned(61)
44 # bytes(4)
ABCD0000
18 3E # unsigned(62)
A1 # map(1)
01 # unsigned(1)
A4 # map(4)
01 # unsigned(1)
02 # unsigned(2)
20 # negative(0)
01 # unsigned(1)
21 # negative(1)
58 20 # bytes(32)
D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9
E354089BBE13
22 # negative(2)
58 20 # bytes(32)
F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E
79A3B4E47120
Tiloca, et al. Expires September 10, 2020 [Page 40]
Internet-Draft Group OSCORE Profile of ACE March 2020
Figure 14: Example CWT with OSCORE parameters.
If the client has requested an update to its access rights using the
same pairwise OSCORE Security Context, which is valid and authorized,
the AS MUST omit the 'cnf' parameter in the response to the client.
Instead, the updated Access Token conveyed in the AS-to-C response
MUST include a 'cnf' claim specifying a 'kid' field, as defined in
Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. The 'kid'
field has as value a CBOR byte string, with value the same value of
the 'req_cnf' parameter from the C-to-AS request for updating rights
to the Access Token (see Figure 11). This information, i.e. the
value of the 'clientId' and 'contextId' parameters in Figure 11,
needs to be included in the Access Token, in order for the RS to
identify the previously generated pairwise OSCORE Security Context.
Figure 15 shows an example of such an AS response, with payload in
CBOR diagnostic notation without the tag and value abbreviations.
The access token has been truncated for readability.
Header: Created (Code=2.01)
Content-Type: "application/ace+cbor"
Payload:
{
"access_token" : h'a5037674656d7053656e73 ...'
(remainder of CWT omitted for brevity),
"profile" : "coap_group_oscore",
"expires_in" : 3600
}
Figure 15: Example AS-to-C Access Token response with the Group
OSCORE profile, for update of access rights.
Figure 16 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations.
Tiloca, et al. Expires September 10, 2020 [Page 41]
Internet-Draft Group OSCORE Profile of ACE March 2020
{
"aud" : "tempSensorInLivingRoom",
"iat" : "1360189224",
"exp" : "1360289224",
"scope" : "temperature_h",
"cnf" : {
"kid" : h'458241004199'
}
}
Figure 16: Example CWT with OSCORE parameters for update of access
rights.
A.2.2.1. Public Key Hash as Client Credential
As a possible optimization to limit the size of the Access Token, the
AS may specify as value of the 'client_cred' claim simply the hash of
the Client's public key. The specifically used hash-function MUST be
collision-resistant on byte-strings, and MUST be selected from the
"Named Information Hash Algorithm" Registry defined in Section 9.4 of
[RFC6920].
In particular, the AS provides the Client with an Access Token as
defined in Appendix A.2.2, with the following differences.
The AS prepares INPUT_HASH as follows, with | denoting byte string
concatenation.
o If the public key has COSE Key Type OKP, INPUT_HASH = i, where 'i'
is the x-parameter of the COSE_Key specified in the 'client_cred'
parameter of the Token request.
o If the public key has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2),
where 'i_1' and 'i_2' are the x-parameter and y-parameter of the
COSE_Key specified in the 'client_cred' parameter of the Token
request, respectively.
o If the public key has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2),
where 'i_1' and 'i_2' are the n-parameter and e-parameter of the
COSE_Key specified in the 'client_cred' parameter of the Token
request.
Then, the AS hashes INPUT_HASH according to the procedure described
in [RFC6920], with the output OUTPUT_HASH in binary format, as
described in Section 6 of [RFC6920].
Finally, the AS includes a single entry within the 'client_cred'
claim of the Access Token. This entry has label "kid" (3) defined in
Tiloca, et al. Expires September 10, 2020 [Page 42]
Internet-Draft Group OSCORE Profile of ACE March 2020
Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession], and has
OUTPUT_HASH as value, encoded as CBOR byte string.
Upon receiving the Access Token, the RS processes it according to
Appendix A.3.2, with the following differences.
The RS considers the content of the 'client_cred' claim as the hash
of the public key associated to the signing private key that the
Client uses in the OSCORE group, which is identified by the
'context_id' parameter.
The RS MAY additionally request the Group Manager of the OSCORE group
for the public key of that Client, as described in
[I-D.ietf-ace-key-groupcomm-oscore], specifying as Sender ID of that
Client in the OSCORE group the value of the 'salt_input' claim
included in the Access Token.
In such a case, the RS MUST check that the hash of the key retrieved
from the Group Manager matches the hash retrieved from the
'client_cred' claim of the Access Token. The RS MUST calculate the
hash using the same method as the AS, described above, and using the
same hash function. The hash function used can be determined from
the information conveyed in the 'client_cred' claim, as the procedure
described in [RFC6920] also encodes the used hash function as
metadata of the hash value.
A.2.2.2. Client Credential Claim
The 'client_cred' claim provides an asymmetric key that the Client
owning the Access Token wishes to use as its own public key, but
which is not used as proof-of-possession key.
This parameter follows the syntax of the 'cnf' claim from Section 3.1
of [I-D.ietf-ace-cwt-proof-of-possession] when including Value Type
"COSE_Key" (1) and specifying an asymmetric key. Alternative Value
Types defined in future specifications are fine to consider if
indicating a non-encrypted asymmetric key.
A.3. Client-RS Communication
This section details the POST request and response to the /authz-info
endpoint between the Client and the RS. With respect to the
exchanged messages and their content, the Client and the RS perform
as defined in Section 4 of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile].
That is, the Client generates a nonce N1 and posts it to the RS,
together with the Access Token that includes the material provisioned
Tiloca, et al. Expires September 10, 2020 [Page 43]
Internet-Draft Group OSCORE Profile of ACE March 2020
by the AS. Then, the RS generates a nonce N2, and derives a pairwise
OSCORE Security Context as described Section 3.2 of [RFC8613]. In
particular, it uses the two nonces established with the Client and
two shared secrets, together with additional pieces of information
specified in the Access Token.
The proof-of-possession required to bind the Access Token to the
Client is implicitly performed by generating the pairwise OSCORE
Security Context using the pop-key as part of the OSCORE Master
Secret, for both the Client and the RS. In addition, the derivation
of the pairwise OSCORE Security Context takes as input also
information related to the OSCORE group, i.e. the Master Secret and
Group Identifier of the group, as well as the Sender ID of the Client
in the group. Hence, the derived pairwise OSCORE Security Context is
also securely bound to the Group OSCORE Security Context of the
OSCORE Group.
Therefore, an attacker using a stolen Access Token cannot generate a
valid pairwise OSCORE Security Context and thus cannot prove
possession of the pop-key. Also, if a Client legitimately owns an
Access Token but has not joined the OSCORE group, that Client cannot
generate a valid pairwise OSCORE Security Context either, since it
lacks the Master Secret used in the OSCORE group.
Besides, just as in the main mode (see Section 4), the RS is able to
verify whether the Client has indeed the claimed Sender ID and public
key in the OSCORE group.
A.3.1. C-to-RS POST to authz-info Endpoint
The Client MUST generate a nonce N1 and post it to the /authz-info
endpoint of the RS together with the Access Token, as defined in
Section 4.1 of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile].
The same recommendations, considerations and behaviors defined in
Section 4.1 of [I-D.ietf-ace-oscore-profile] hold.
A.3.2. RS-to-C: 2.01 (Created)
The RS MUST verify the validity of the Access Token as defined in
Section 4.2, with the following modifications.
o The RS checks that the 'cnf' claim is included in the Access Token
and that it contains an OSCORE_Security_Context object.
o The RS checks that the 'client_cred' claim is included in the
Access Token.
Tiloca, et al. Expires September 10, 2020 [Page 44]
Internet-Draft Group OSCORE Profile of ACE March 2020
o The RS considers the content of the 'client_cred' claim 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
the claimed Client retrieved from the Group Manager (see
Section 4.2).
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
equivalent to the CoAP code 4.00 (Bad Request).
If the Access Token is valid and further checks on its content are
successful, the RS MUST generate a nonce N2 and include it 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].
Further recommendations, considerations and behaviors defined in
Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this
specification.
A.3.3. OSCORE Setup - Client Side
Once having received the 2.01 (Created) response from the RS,
following the POST request to the authz-info endpoint, the Client
MUST extract the nonce N2 from the 'cnonce' parameter and the client
identifier from the 'clientId' parameter (if present) in the CBOR map
in the payload of the response.
Note that, if present in the 2.01 (Created) response, the 'clientId'
parameter supersedes the analogous parameter possibly provided by the
AS to C in Appendix A.2.2. Also, note that this identifier is 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
Sender ID of C in the OSCORE group.
Then, the Client performs the following actions, in order to set up
and fully derive the pairwise OSCORE Security Context for
communicating with the RS.
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
of the OSCORE group, as specified by the Client in the
'context_id' parameter of the Client-to-AS request; ii) the nonce
N1; iii) the nonce N2; and iv) CID, i.e. the value in the
contextId parameter of the OSCORE_Security_Context object provided
in the 'cnf' parameter of the Access Token response from the AS.
The concatenation occurs in this order: ID Context = GID | N1 |
N2 | CID, where | denotes byte string concatenation.
Tiloca, et al. Expires September 10, 2020 [Page 45]
Internet-Draft Group OSCORE Profile of ACE March 2020
Note that, if the Client wishes to update its access rights as
defined in Appendix A.2.1, the 'kid_arr' in Figure 10 for the C-
to-AS request MUST be built as follows. The 'IdContext' element
has as value the value of the 'contextId' parameter of the
OSCORE_Security_Context object, as specified in the 'cnf'
parameter of the original Access Token response from the AS.
Since the client is aware of the sizes of N1, N2 and GID, it can
retrieve this value as the CID component from the ID Context of
the pairwise OSCORE Security Context as defined above, i.e. by
considering only the appropriate amount of bytes from the end.
o The Client MUST set the updated Master Salt of the pairwise OSCORE
Security Context as the concatenation of SaltInput, MSalt, the
nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the
Sender ID that the Client has in the OSCORE group, which is known
to the Client as a member of the OSCORE group; ii) MSalt is the
(optional) Master Salt in the pairwise OSCORE Security Context;
and iii) GMSalt is the (optional) Master Salt in the Group OSCORE
Security Context, which is known to the Client as a member of the
OSCORE group. The concatenation occurs in this order: Master Salt
= SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte
string concatenation. Optional values, if not specified, are not
included in the concatenation.
o The Client MUST set the Master Secret of the pairwise OSCORE
Security Context to the concatenation of MSec and GMSec, where: i)
MSec is the value of the 'ms' parameter in the
OSCORE_Security_Context object of the 'cnf' parameter, received
from the AS in Appendix A.2.2; while ii) GMSec is the Master
Secret of the Group OSCORE Security Context, which is known to the
Client as a member of the OSCORE group.
o The Client MUST set the Recipient ID as indicated in the
corresponding parameter received from the AS in Appendix A.2.2,
i.e. to the value of the 'serverId' parameter in the
OSCORE_Security_Context object of the 'cnf' parameter.
o The Client MUST set the AEAD Algorithm, HKDF, and Replay Window as
indicated in the corresponding parameters received from the AS in
Appendix A.2.2, if present in the OSCORE_Security_Context object
of the 'cnf' parameter. In case these parameters are omitted, the
default values are used as described in Section 3.2 of [RFC8613].
o The client MUST set the Sender ID as indicated in the response
from the AS in Appendix A.2.2, i.e. to the value of the 'clientId'
parameter in the OSCORE_Security_Context object of the 'cnf'
parameter.
Tiloca, et al. Expires September 10, 2020 [Page 46]
Internet-Draft Group OSCORE Profile of ACE March 2020
Finally, the client MUST derive the complete pairwise OSCORE Security
Context following Section 3.2.1 of [RFC8613].
From then on, when communicating with the RS to access the resources
as specified by the authorization information, the Client MUST use
the newly established pairwise OSCORE Security Context or the Group
OSCORE Security Context of the OSCORE Group where both the Client and
the RS are members.
If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or 'clientId' both from the AS and
in the 2.01 (Created) response from the RS), the Client MUST stop the
exchange, and MUST NOT derive the pairwise OSCORE Security Context.
The Client MAY restart the exchange, to get the correct security
material.
Then, the Client uses this pairwise OSCORE Security Context to send
requests to RS protected with OSCORE. In the first request sent to
the RS, the Client MAY include the kid context if the application
needs to, with value the ID Context of the pairwise OSCORE Context as
described above. Besides, the Client uses the Group OSCORE Security
Context for protecting unicast requests to the RS, or multicast
requests to the OSCORE group including also the RS.
A.3.4. OSCORE Setup - Resource Server Side
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
following 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
Context as the concatenation of: i) GID, i.e. the Group Identifier
of the OSCORE group, as specified in the 'contextId' parameter of
the OSCORE_Security_Context object, in the 'cnf' claim of the
Access Token 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 parameter of the OSCORE_Security_Context object
provided in the 'cnf' claim of the Access Token. The
concatenation occurs in this order: ID Context = GID | N1 | N2 |
CID, where | denotes byte string concatenation.
o The RS MUST set the new Master Salt of the pairwise OSCORE
Security Context as the concatenation of SaltInput, MSalt, the
nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the
Sender ID that the Client has in the OSCORE group, as specified in
the 'salt_input' claim included in the Access Token received from
the Client (see Appendix A.3.1); ii) MSalt is the (optional)
Tiloca, et al. Expires September 10, 2020 [Page 47]
Internet-Draft Group OSCORE Profile of ACE March 2020
Master Salt in the pairwise OSCORE Security Context as specified
in the 'salt' parameter in the OSCORE_Security_Context object of
the 'cnf' claim, included in the Access Token received from the
Client; and iii) GMSalt is the (optional) Master Salt in the Group
OSCORE Security Context, which is known to the RS as a member of
the OSCORE group. The concatenation occurs in this order: Master
Salt = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte
string concatenation. Optional values, if not specified, are not
included in the concatenation.
o The RS MUST set the Master Secret of the pairwise OSCORE Security
Context to the concatenation of MSec and GMSec, where: i) MSec is
the value of the 'ms' parameter in the OSCORE_Security_Context
object of the 'cnf' claim, included in the Access Token received
from the Client (see Appendix A.3.1); while ii) GMSec is the
Master Secret of the Group OSCORE Security Context, which is known
to the RS as a member of the OSCORE group.
o The RS MUST set the Sender ID of the pairwise OSCORE Security
Context from the corresponding parameter received from the Client
in the Access Token (see Appendix A.3.1), i.e. to the value of the
'serverId' parameter in the OSCORE_Security_Context object of the
'cnf' claim.
o The RS MUST set the Recipient ID of the pairwise OSCORE Security
Context to what indicated in the corresponding parameter received
from the Client in the Access Token (see Appendix A.3.1), i.e. to
the value of the 'clientId' parameter in the
OSCORE_Security_Context object of the 'cnf' claim.
o The RS MUST set the AEAD Algorithm, HKDF, and Replay Window from
the corresponding parameters received from the Client in the
Access Token (see Appendix A.3.1), if present in the
OSCORE_Security_Context object of the 'cnf' claim. In case these
parameters are omitted, the default values are used as described
in Section 3.2 of [RFC8613].
Finally, the RS MUST derive the complete pairwise OSCORE Security
Context following Section 3.2.1 of [RFC8613].
Once having completed the derivation above, the RS MUST associate the
authorization information from the Access Token with the just
established pairwise OSCORE Security Context. Furthermore, as
defined in Section 4.2, the RS MUST associate the authorization
information from the Access Token with the Group OSCORE Security
Context.
Tiloca, et al. Expires September 10, 2020 [Page 48]
Internet-Draft Group OSCORE Profile of ACE March 2020
Then, the RS uses this pairwise OSCORE Security Context to verify
requests from and send responses to the Client protected with OSCORE,
when this Security Context is used. If OSCORE verification fails,
error responses are used, as specified in Section 8 of [RFC8613].
Besides, the RS uses the Group OSCORE Security Context to verify
(multicast) requests from and send responses to the Client protected
with Group OSCORE. If Group OSCORE verification fails, error
responses are used, as specified in Section 7 of
[I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming
request, if OSCORE or Group OSCORE verification succeeds, the
verification of access rights is performed as described in
Appendix A.3.5.
After the expiration of the Access Token related to a pairwise OSCORE
Security Context and to a Group OSCORE Security Context, the RS MUST
NOT use the pairwise OSCORE Security Context and MUST respond with an
unprotected 4.01 (Unauthorized) error message to received requests
that correspond to a security context with an expired token. Also,
if the Client uses the Group OSCORE Security Context to send a
request for any resource intended for OSCORE group members and that
requires an active Access Token, the RS MUST respond with a 4.01
(Unauthorized) error message protected with the Group OSCORE Security
Context.
A.3.5. Access Rights Verification
The RS MUST follow the procedures defined in Section 4.4.
Additionally, if the RS receives an OSCORE-protected request from a
Client, the RS processes it according to [RFC8613].
If the OSCORE verification succeeds, and the target resource requires
authorization, the RS retrieves the authorization information from
the Access Token associated to the pairwise OSCORE Security Context
and to the Group OSCORE Security Context. Then, the RS MUST verify
that the action requested on the resource is authorized.
The response code MUST be 4.01 (Unauthorized) in case the Client has
not used either of the two Security Contexts associated with the
Access Token, or if the RS has no valid Access Token for the Client.
A.4. Secure Communication with the AS
The same considerations for secure communication with the AS as
defined in Section 5 hold.
Tiloca, et al. Expires September 10, 2020 [Page 49]
Internet-Draft Group OSCORE Profile of ACE March 2020
A.5. Discarding the Security Context
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
Security Context.
Additionally, they MUST follow what is defined in the main mode of
the profile (see Section 6), with respect to the Group OSCORE
Security Context.
The Client or RS can acquire a new Group OSCORE Security Context, by
re-joining the OSCORE group, e.g. by using the approach defined in
[I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client
SHOULD request a new Access Token and post it to the RS, in order to
establish a new pairwise OSCORE Security Context and bind it to the
Group OSCORE Security Context obtained upon re-joining the group.
A.6. CBOR Mappings
The new parameters defined in this document MUST be mapped to CBOR
types as specified in Figure 6, with the following addition, using
the given integer abbreviation for the map key.
/----------------+----------+------------\
| Parameter name | CBOR Key | Value Type |
|----------------+----------+------------|
| client_cred | TBD5 | map |
\----------------+----------+------------/
Figure 17: CBOR mappings for new parameters.
The new claims defined in this document MUST be mapped to CBOR types
as specified in Figure 7, with the following addition, using the
given integer abbreviation for the map key.
/--------------+----------+------------\
| Claim name | CBOR Key | Value Type |
|--------------+----------+------------|
| client_cred | TBD5 | map |
\--------------+----------+------------/
Figure 18: CBOR mappings for new claims.
A.7. Security Considerations
The dual mode of this profile inherits the security considerations
from the main mode (see Section 8), as well as from the security
considerations of the OSCORE profile of ACE
Tiloca, et al. Expires September 10, 2020 [Page 50]
Internet-Draft Group OSCORE Profile of ACE March 2020
[I-D.ietf-ace-oscore-profile]. Also, the security considerations
about OSCORE [RFC8613] hold for the dual mode of this profile, as to
the specific use of OSCORE.
A.8. Privacy Considerations
The same privacy considerations as defined in the main mode of this
profile apply (see Section 9).
In addition, as this profile mode also uses OSCORE, the privacy
considerations from [RFC8613] apply as well, as to the specific use
of OSCORE.
Furthermore, this profile mode inherits the privacy considerations
from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile].
Appendix B. Profile Requirements
This appendix lists the specifications on this profile based on the
requirements of the ACE framework, as requested in Appendix C of
[I-D.ietf-ace-oauth-authz].
o (Optional) discovery process of how the Client finds the right AS
for an RS it wants to send a request to: Not specified.
o Communication protocol the Client and the RS must use: CoAP.
o Security protocol(s) the Client and RS must use: Group OSCORE,
i.e. exchange of secure messages by using a pre-established Group
OSCORE Security Context. The optional dual mode defined in
Appendix A additionally uses OSCORE, i.e. establishment of a
pairwise OSCORE Security Context and exchange of secure messages.
o How the Client and the RS mutually authenticate: Explicitly, by
possession of a common Group OSCORE Security Context and usage of
digital countersignatures, embedded in messages protected with
Group OSCORE. In the optional dual mode defined in Appendix A,
this may also happen implicitly, by possession of a common OSCORE
Security Context (when using OSCORE).
o Content-format of the protocol messages: "application/ace+cbor".
o Proof-of-Possession protocol(s) and how to select one; which key
types (e.g. symmetric/asymmetric) supported: Group OSCORE
algorithms; distributed and verified asymmetric keys. In the
optional dual mode defined in Appendix A: OSCORE algorithms; pre-
established symmetric keys
Tiloca, et al. Expires September 10, 2020 [Page 51]
Internet-Draft Group OSCORE Profile of ACE March 2020
o profile identifier: coap_group_oscore
o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP
(+ TLS/DTLS/OSCORE).
o How the client talks to the AS for requesting a token: HTTP/CoAP
(+ TLS/DTLS/OSCORE).
o How/if the authz-info endpoint is protected: Not protected.
o (Optional) other methods of token transport than the authz-info
endpoint: Not specified.
Acknowledgments
The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave
Robin, Jim Schaad and Goeran Selander for their comments and
feedback.
The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC.
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
Kista SE-16440 Stockholm
Sweden
Email: marco.tiloca@ri.se
Rikard Hoeglund
RISE AB
Isafjordsgatan 22
Kista SE-16440 Stockholm
Sweden
Email: rikard.hoglund@ri.se
Tiloca, et al. Expires September 10, 2020 [Page 52]
Internet-Draft Group OSCORE Profile of ACE March 2020
Ludwig Seitz
Combitech
Djaeknegatan 31
Malmoe SE-21135 Malmoe
Sweden
Email: ludwig.seitz@combitech.se
Francesca Palombini
Ericsson AB
Torshamnsgatan 23
Kista SE-16440 Stockholm
Sweden
Email: francesca.palombini@ericsson.com
Tiloca, et al. Expires September 10, 2020 [Page 53]