Re: [Ace] ace-oscoap-joining comments

Marco Tiloca <> Fri, 29 June 2018 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADA81130E0F for <>; Fri, 29 Jun 2018 08:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmRxl4yXEqrn for <>; Fri, 29 Jun 2018 08:36:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57F67130DCA for <>; Fri, 29 Jun 2018 08:36:09 -0700 (PDT)
Received: from 1fYvRO-000dgf-VB by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1fYvRP-000dhT-TF; Fri, 29 Jun 2018 08:36:07 -0700
Received: by emcmailer; Fri, 29 Jun 2018 08:36:07 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1fYvRO-000dgf-VB; Fri, 29 Jun 2018 08:36:06 -0700
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 29 Jun 2018 17:36:06 +0200
References: <>
From: Marco Tiloca <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw=
Message-ID: <>
Date: Fri, 29 Jun 2018 17:36:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="wZdc8f6Sf6JeTUi2GHhhR1u8qSeGgn1sQ"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-PolicySMART: 14510320
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <>
Subject: Re: [Ace] ace-oscoap-joining comments
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2018 15:36:17 -0000

Hello Peter,

Thank you very much for your review! Please, find our answers in line.

We took into account your comments for producing the latest version of
the draft [1].



On 2018-04-19 11:36, peter van der Stok wrote:
> Hi authors,
> Below comments on the draft-tiloca-ace-oscoap-joining-03.
> The draft seems to be pretty clear, but then, I did not try to
> implement it.
> Comments on details, typos, structure, and questions are mixed
> together in reading sequence.
> title: I expect draft-tiloca-ace-oscore-joining (oscoap is in the past)

[MT] Indeed, however we would need to submit a new version -00.

> page 3 section 1. dtls-authorize and oscore-profile are mentioned
> quite prominently here, but almost not used elsewhere in the draft
> (section 6), and only informative. suggest to remove here.

[MT] We have removed the references from this paragraph, and made
dtls-authorize informative. However, we think to keep oscore-profile
normative, due to a number of COSE Key parameters used in the Join
Response (Section 4.2) and defined in the OSCORE profile document.

> section 1.1 The phrase "message exchanges .... useful terminology" may
> go for me. (mentioned in authz and others already).
> Is reference to oAuth 2.0 not sufficient, ace-actors is not really
> needed IMO.

[MT] We removed the sentence and the following reference to ace-actors.

> I miss Group Manager in the terminology. here relation with RS can be
> mentioned, not needed in section 2.

[MT] The paragraph pointing at OSCORE and oscore-groupcomm has been
extended as follows: "These include the concept of Group Manager, as the
entity responsible for a set of groups where communications are secured
with OSCORE. In this specification, the Group Manager acts as Resource

> Section 2 bullet 3 is quite complex text:
> Suggestion:
> The Authorization Server (AS) authorizes joining nodes to join ....
> The AS MAY release access tokens for other purposes than accessing
> join resources; for example: to release......
> of OSCORE groups

[MT] We took into account your suggestions and rephrased the text.

> Page 5
> Is paragraph "All communication ...... ACE Framework [authz]" not
> almost identical to
> "communications between ..... this specification". If not,
> reformulation is clearly needed.

[MT] We reformulated as follows: i) a first single-sentence paragraph
points at secure communication based on CoAP; ii) a second paragraph on
the secure communication required between joining node and Group
Manager; and iii) a third paragraph about secure communication with the
AS, either between the AS and the joining node or between the AS and the
Group Manager.

> page 5 point 1. suggestion for last phrase: With the response from the
> AS, the joining node starts or continues a secure channel with the
> Group Manager.

[MT] We rephrased the text as: "The joining node will start or continue
using a secure communication channel with the Group Manager, according
to the response from the AS."

> point 2 Collapse phrase 2 and 3 to: "Then, a joining node must
> establish .....first time".  May be add a reference to DTLS or other
> recommended alternatives?

[MT] We rephrased the text as: "After that, a joining node must have a
secure communication channel established with the Group Manager, before
starting to join an OSCORE group under that Group Manager (see Section
4). Possible alternatives to provide a secure communication channel
include DTLS [RFC6347] and OSCORE [I-D.ietf-core-object-security]."

> point 4 in the OSCORE group -> with the OSCORE group members.

[MT] We rephrased it as "with the other members of the OSCORE group".

> Suggest a point 5 to say that the secure channel is maintained for
> between JN and GM

[MT] Done.

> Section 3 is about JN to AS but mentions secure channel between JN and
> GM. That is confusing, because I expect text about secure channel
> between JN and AS.
> I suggest to remove the discovery with the aid of resource-directory,
> or add more text and specify a resource-type rt=) for the AS.

[MT] We have rephrased to put more focus on the exchange between JC-AS.
Also, we removed the text pointing at the discovery based on the
Resource Directory.

> section 3.1 under scope parameter first *: I failed to find the
> "dynamic" component of the scope parameter in [key-groupcomm]

[MT] Sorry for the confusion. What is dynamic, or actually variable, is
not the "scope" parameter and its size, but part of the value of the
actual Gid associated to the group. This is to admit Gid formats with
multiple parts, some of which are dynamic in value, such as the case of
Group Prefix and (variable) Group Epoch (see Appendix C of

[MT] We have rephrased the second sentence as: "The value of this
identifier may not fully coincide with the Gid value currently
associated to the group, e.g. if the Gid is composed of a variable part
such as a Group Epoch (see Appendix C of [I-D.ietf-core-oscore-groupcomm])."

> get-pub-keys. I wonder why you want to separate the public key storage
> from the GM. What is the operational advantage?; I only see added 
> complexity.

[MT] The oscore-groupcomm document defines a "broad interface" where
public keys of group members can alternatively be stored at a separate
trusted repository other than the Group Manager. However,
oscore-groupcomm does recommend that the Group Manager acts as public
key store (see its Section 6).

[MT] To keep consistency, we are preserving both the same possibilities
also in this document. Do you think that this ACE-based approach should
explicitly be limited to the Group Manager as public key store?

[MT] We have anyway removed the get_pub_keys parameter from the
Authorization Request, also based on a discussion with Jim where we
agreed that the AS has no actual reason to know about this specific wish
from the joining node.

> section 3.2 "The AS is responsible.....Group Manager" I don't
> understand this phrase.

[MT] Now rephrased as: "The AS is responsible for authorizing the
joining node to join specific OSCORE groups, according to join policies
enforced on behalf of the respective Group Manager.

> The "exp" parameter; it MUST be present and then is out of scope?

[MT] That was ambiguous, we rephrased it to be more aligned with Section
4.2.2 of RFC6749. What is out of scope if defining alternative means
usable instead of "exp", hence required to be mandatory.

> The phrase "in case the value......include the "scope" parameter" is
> difficult to read.
> I suggest: The AS must include the "scope" parameter in the response,
> when the returned value of the response differs from the one in the
> request. (or anything shorter)

[MT] We took into account your suggestions and rephrased the text.

> section 4 page 7
> /what specified/ what is specified/

[MT] Fixed.

> section 4.2 page 8
> /yields to a positive/yields a positive/

[MT] Fixed.

> section 5
> Again why separate key storage

[MT] See reply to the comment above.

> first bullet: IMO, it does not hurt to provide the public key, when
> already known; specifying conditions in the protocol  increases the
> probability of errors. (Others may have different opinions given the
> need of payload reduction)

[MT] Good point to consider. We have rephrased the last sentence as: "In
this case, the joining node may not provide again its own public key to
the Group Manager, in order to limit the size of the join request."

> page 11
> "Before sending the join response .... this specification" suggest to
> move this phrase to section 6.

[MT] Done, now placed right before the last paragraph of Section 6.

> section 6. I suggest to add the reference to oscore-groupcomm when
> referring to the (sections) or (appendix).

[MT] Done.

> Hope this helps,

[MT] It definitely does, thanks a lot again!

> Peter

Marco Tiloca, PhD
Research Institutes of Sweden
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.