Re: [Lake] EDHOC Implementation Considerations for parameters

[Marco Tiloca <[e-mail]>]

Hello Brian,

On 2024-02-20 16:10, Sipos, Brian J. wrote:

> All,
>
> I’ve been looking through the EDHOC Implementation Considerations 
> draft [1] and there is a lot of very valuable information in there, 
> especially around the notion of side processing.
>

==>MT

Thanks a lot for your interest and support!

<==

> (As a secondary question, was there a source for this term “side 
> processing” or was it created for this document?)
>

==>MT

I've just made the term up and started using it. It seems to have worked 
well :-)

<==

> One thing in EDHOC that I am trying to reconcile with an integration 
> in a new environment is how to express/agree/negotiate precondition 
> parameters (like Method [2]) to being able to actually invoke EDHOC 
> procedures and expect them to succeed with a should-be-interoperable 
> but external peer.
>
> I see in the OSCORE integration document there is a specific listing 
> of available EDHOC parameters [3] that an endpoint can express to help 
> a peer choose what to offer in the first EDHOC message that will have 
> a good chance to succeed. Does it make sense to cover the same needed 
> parameters in a less integration- or transport-specific way in the 
> Implementation Considerations doc? Even just having a list of “these 
> are the things that must or can be expressed before starting an EDHOC 
> procedure to ensure it will complete successfully …” would, I think, 
> be helpful to implementors.
>

==>MT

Yes, it does make sense that two peers can early coordinate on a set of 
parameters that sets the ground for a successful EDHOC execution.

In practice, this is about the two peers coordinating on the EDHOC 
application profile to use (see Section 3.9 of [2]), based on their 
mutual support and preference.

As you notice, a first step in that direction was taken in [3]. As you 
also notice, that approach specifically considers link target 
attributes. Those are used to convey "individual parameters" in 
weblinks, and thus the corresponding support on the side of a CoAP 
server acting as EDHOC peer.

A different, but still setup-specific approach is used in another 
document at [4], which defines the EDHOC and OSCORE transport profile of 
the ACE framework for access control. In this case, an Authorization 
Server (AS) issues an Access Token to a Client for accessing protected 
resources at a Resource Server (RS). The Client and the RS will act as 
EDHOC Initiator and Responder, respectively, and the AS also provides 
the Client with information that describes what the RS supports as an 
EDHOC peer. This builds on a dedicated EDHOC_Information object (see 
Section 3.4 of [4]).


Since you are rightly asking about a possible setup-independent 
approach, we have actually started to work in that direction, and you 
may be interested to check the document at [5].

In fact, the document introduces more general means for coordinating on 
the supported EDHOC application profiles, and it especially defines two 
coordination means:

* The registration of pre-defined EDHOC application profiles, identified 
by an integer number.

* A canonical CBOR data item that can be used to describe an EDHOC 
application profile.

As to the actual distribution of this information, so far it has looked 
better to leave freedom about how it can exactly happen.

For example, if what an EDHOC peer supports is described in one such 
CBOR data item or just referenced by an integer pointing to a registered 
application profile, this information can be: retrieved as a result of a 
more general discovery process; or retrieved/provided during the 
retrieval/provisioning of that peer's public authentication credential; 
or obtained during the execution of a device on-boarding/registration 
workflow.

We plan to submit a revised version -01 of [5] before the next cut-off 
deadline, and we certainly welcome more feedback and input!

Thanks,
/Marco


[4] https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/

[5] https://datatracker.ietf.org/doc/draft-tiloca-lake-app-profiles/

<==

> Thanks for your feedback,
>
> Brian S.
>
> [1] 
> https://www.ietf.org/archive/id/draft-tiloca-lake-edhoc-implem-cons-01.html
>
> [2] 
> https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-23.html#section-3.2
>
> [3] 
> https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-10.html#section-6
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se