Re: [Lake] [Ace] ace-ake-auth updates for latest EDHOC principles

[Göran Selander <[e-mail]>]

Some additional comments inline:

From: Ace <[e-mail]> on behalf of Michael Richardson <[e-mail]>
Date: Wednesday, 12 October 2022 at 15:24
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Ace] ace-ake-auth updates for latest EDHOC principles

The authors of draft-selander-ace-ake-auth have been discussing how to update
this draft to reflect some of the changes in EDHOC.  Specifically, there is a
concern that ace-ake-auth reveals too much in message_1, things which EDHOC
has worked hard to keep private.
One planned change in the next version is to shift the trust model
from:

  *   the trusted third party, W, is trusted to decide to which authenticator V the identity of the device U is revealed
to:

  *   the device U decides to which authenticator V it reveals its identity.
Since the authentication credential of U may be large it is still desirable that V can obtain it from W rather than over the constrained link between U and V, but - to match the changed trust assumption above - at a different time in the protocol: after message_3 instead of before message_2.

For those that don't know ace-ake-auth, it fits into the "Ultra-constrained"
onboarding column for the diagram that was part of
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-03
(and was in the IoT-Dir wiki, which needs to be resurrected.  The diagram is
also visible at:
https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-bbfeee37309f6b5e&q=1&e=ed56df95-0487-4240-99b5-7a62a7af1bd5&u=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fenrollment-roadmap%2Fblob%2Fmaster%2Ftechnology-components.svg )

The ACE connection is that the backend (aka "BRSKI-MASA" protocol equivalent)
was leveraged against the ACE mechanism.  There is now some reconsideration
here.  Fundamentally, it would be nice to know where the document adoption is
going so that we'd know where to have public discussions about the trade-offs.
(please note reply-to)
Michael’s way of saying that LAKE is a natural candidate. This draft is building on EDHOC and matches a request from the LAKE WG to produce an example showing how the External Authorization Data message fields can be applied.

The location of the MASA (aka "W" in the document) is provided in the clear
during message_1, with the actual device serial number encrypted to W using a
static DH key that the pledge ("U") has been provisioned with.

It would be nice to move some of this from message_1 to message_3, which
would guard better against on-path attacks that impersonate V.
See above.
Göran

The URL
provided during message_1 is visible to any observers, and since this is
onboarding, any network privacy is not yet applicable.

OTH, the authorization step needs to complete before message_2 can properly
be formed, as it contains enough of the RFC8366 constrained-voucher semantics
that it allows the pledge (U) to authenticate V.

Knowing the identity of the MASA may tell you a lot about the device in
question.  This is a place where having many MASA outsourced to a big MASA
helps with privacy.  It's also a place where perhaps oblivious-HTTP might
help.

There is a question about what the security policy of W is.
Is it TOFU-ish, aka promiscious MASA, or does *it* know which device has been
sold to whom?

Also, the URL for the MASA is ideally very very short :-)

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide