Subject: [Ace] Comments on draft-ietf-ace-pubsub-profile-00

From: Marco Tiloca <[email-masked]>
Date: Fri, 10 Jan 2020 15:32:58 +0000

Hi,

Please, see below a couple of comments and thoughts on this profile.

1. In Section 7, the second paragraph says "critical that only
authorized Publishers can publish", i.e. it points at an authorization
aspect. However, the sentence continues with opening for a purely
symmetric key-based solution, in case source-authentication is not
strictly needed and anonymity is desired.

I suppose that this paragraph is actually intended to discuss the latter
aspect, so it may be better to rephrase it to clarify its focus on
source- vs. group- authentication, rather than on authorization to
publish. That is, authorization to publish to that topic is still
enforced in either case, by AS2 providing the topic-related symmetric
key to the publisher.

2. The document needs to define how to construct the AEAD nonce used to
protect/verify a published message.

Unless only one publisher per topic is admitted, this seems to require
to have also a Publisher ID to use for constructing the nonce. Publisher
IDs would have to be unique under the same topic, which AS2 is in a
position to ensure.

A possible way to manage and distribute Publisher IDs can be:

a) In the joining request payload (see Figure 5), the publisher provides
its own public key in 'client_cred' but without a 'kid'.

b) The joining response (see Figure 6) includes a new parameter,
specifying a Publisher ID "PID" determined by AS2 and unique within that
topic. This is similar to what is done in ace-key-groupcomm-oscore by
the Group Manager upon a new member's joining.

c) AS2 stores the publisher's public key, adding as its 'kid' field the
"PID" from step (b).

d) A subscriber learns the Publisher ID "PID", whenever retrieving the
public key of that publisher from AS2.

e) When publishing a message, the publisher includes its own Publisher
ID "PID" received at step (b) above, in the 'kid' of the unprotected
field of 'countersign' (see Figure 12).

This should still be aligned to what described now in the draft, but
entrusting AS2 to manage the 'kid' of public keys as Publisher IDs, so
ensuring their uniquess within a topic.

Then the actual nonce construction can possibly be along the lines of
the one for (Group) OSCORE, see
https://tools.ietf.org/html/rfc8613#section-5.2

Best,
/Marco

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se