authz with U as R and V as I

[chrysn]

(Moved from EricssonResearch/ace-ake-authz#27)

Processing some deployment scenarios (involving CoAP-over-GATT), I've found that sometimes the roles of I and R would be reversed.

Apart from the aspect of vulnerable-identities, is there anything fundamentally keeping the ENC_U_INFO from being in message 2, and the voucher from being in message 3? The credential database lookup would then be against ID_CRED_R, but that'd be the same interface as for ID_CRED_I.

Let's not sink too much time into this if it turns out to be complicated -- I'm not sure whether running EDHOC over CoAP in reverse flow may not be the better choice in this situation anyway, but if this has ever been contemplated in other places, this issue might be a good spot to spool ideas.

[mcr]

I think that we have made some significant optimizations assuming U as I.
I think that there are different optimizations that occur if V is I.
CoAP-over-GATT probably does not need a discovery process whereby V discovers a U that it should initiate to.

V as I has many advantages when it comes to managing bandwidth.

[chrysn]

Indeed the flow in the GATT case would be that U sends a beacon that contains a 32bit hash of LOC_W, so V would likely already have a good idea of what W would be (given that in a list of peered W, this likely only matches 1 or at most 3) – so the first EAD would only contain LOC_W for confirmation (or maybe not at all).

[geonnave]

At a first glance I think it could work.

Apart from just using EAD_2 / EAD_3 instead of EAD_1 / EAD_2, it would also have some impact on the VREQ/VRES protocol, which currently sends message_1 to W, which is then used in the composition of the Voucher:

external_aad = (
    H(message_1): bstr, / could be changed to `H(message_1 || message_2)` (or even just reuse `TH_3`) /
    CRED_V:       bstr,
)

[geonnave]

If you think #41 addresses your comment, could you please close this issue @chrysn?