[Ace] Re: PoA based Device Registration (draft-vattaparambil-ace-wg-poa-device-reg): Support, suggestions

[Christian Amsüss <[e-mail]>]

Hello Sree,

On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote:
> In this draft, we have assumed a pre-established mutual authentication
> step between the DO and the AS. We haven’t explained it in detail
> because it is an assumption.

The assumption I've been working on is that DO is enrolled to the AS as
a C. Either the authorizations the AS associates with the DO have a
"this may be delegated" flag on them, or the AS simply treats itself as
an RS, where some C (such as the DO) are authorized to utilize the
"register more clients and transfer some authorizations" interface.

As I understand the interfaces we lack, the OAuth dynamic client
registration covers both the creation of a client and giving it the
right scope; for ACE I hope we can do something much slimmer.

> I read a new alternative protocol flow of ACE (L1), this will even
> decrease the load on the client side. We can discuss. I will look into the
> CoRE dynlink you mentioned. Will see how we can use it.

The alternative flow can certainly be a good simplification in some
cases.

It would be a *great* simplification if by the mere request from the DO
it could already issue the token and install it on the RS, and refresh
it on expiry (for this would free the C from the need to ever actually
perform the C-AS protocol). Some prior chats indicate that this would
contradict the ACE architecture where the AS needs to prove that C
actually has that key, but let's discuss that more. (Personally I don't
see anything wrong with the AS issuing a token to C blindly -- the token
will be bound to the key included, and success of EDHOC proves
possession of that key to the RS).

If that larger simplification is possible, the data the C receives from
the DO would not even include AS details any more, but instead would
contain details of the token response (eg. rs_cnf).

> We also do not like to send the credentials in plaintext, we can go with
> EDHOC with key identifiers, but I am not well aware of how this works and
> how to show this in the protocol flow diagram. We can have a discussion on
> this.

The credentials are not sent in plain text in EDHOC: the initiator's
credentials (ie. the token) would only be revealed to the RS after C has
verified that the RS just presented the right rs_cnf.

> The problem with bundling of the AS URI, AS credentials, audience, scope;
> we haven’t thought about it in this way. We had a small thought on multiple
> entities and the scalability of the solution.

Multiple entities definitely make this more complex. If the RSes can be
expresed as a group audience, tools like rs_cnf2 (also from
ace-workflow-and-params) could help.

> We can meet in Paris, me and Olov will participate in person:)

Looking forward to that!

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom