Re: [Lake] [EXT] Re: EDHOC Implementation Considerations for parameters

["Sipos, Brian J." <[e-mail]>]

Marco,

Yes, that draft [5] is actually just what I was looking for. No need to reinvent an encoding for all of those EDHOC options or selection logic. Thanks for this pointer!

 

From: Marco Tiloca <[e-mail]> 
Sent: Wednesday, February 21, 2024 5:54 AM
To: Sipos, Brian J. <[e-mail]>; [e-mail]
Subject: [EXT] Re: [Lake] EDHOC Implementation Considerations for parameters

 

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