Re: [Lake] EDHOC negotiation and errors

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

Göran,

I believe that either your suggestion of a most specific error code or even a less specific code of “credential not accepted, try another” (similar to how HTTP 401 can mean try another credential) and an application profile explaining the progression of different credentials to attempt. The main distinction is that the receiving application can see this differently than the general EDHOC failure and try again in a progressive way.

 

To Michael’s point about using x5u as an alternative, in my case this is for negotiating participation on a network so there is unfortunately no wider network available prior to EDHOC succeeding.

 

From: Göran Selander <[e-mail]> 
Sent: Tuesday, February 21, 2023 8:20 AM
To: Sipos, Brian J. <[e-mail]>; [e-mail]
Subject: [EXT] Re: EDHOC negotiation and errors

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hello Brian,

 

Thanks, great comment!

EDHOC error codes was discussed at IETF 110, slides 5-12 in this set:

 <https://datatracker.ietf.org/meeting/110/materials/slides-110-lake-edhoc-consolidated-01> https://datatracker.ietf.org/meeting/110/materials/slides-110-lake-edhoc-consolidated-01

 

As I remember, looking at slide 11 with the different classes of errors, the focus was on what errors are actionable by the receiving EDHOC engine (without involving an administrator), bearing in mind that there are anyway many things that needs to be agreed upon beforehand as part of the application profile. Class 3 deals with credential/context errors, where for which we apparently didn’t specify any actionable errors. But your example provides an actionable error in this class which may occur even if both endpoints comply with an application profile in terms of credential type and COSE header to use for identification. 

 

One case when this may be useful is if a constrained device communicating with multiple endpoints needs to delete the credential of one endpoint to free space to store that of another. We have the option to reference the credential or send by value, and in this case it could be useful for the receiving endpoint to indicate that it needs to be sent. This feature also allows for a strategy where the sending endpoint could first send a reference, to try to avoid the overhead of a large credential, and then take that cost only if necessary.

 

The simplest solution seems to be an error code which means  “please send the credential by value”. Does that solve your use case?

 

A more elaborate solution is that the error message indicates e.g. supported credential types in the error message using their CBOR representation (33 for x5chain, etc.). I’m a bit hesitant to over-engineer this part, and supported credential types should anyway be known from the application profile. 

 

There is a denial of service aspect we should consider since error messages are unprotected, so at least a security consideration is needed if we go this way. The application profile may set a policy for the use of this. 

 

Another take-away from your input is that we probably should define a private range of error codes (say 32768-65535 like for the EDHOC exporter label).

 

Process-wise, I believe we should be able handle your comment like any other last-call comments (to start real soon now? 😊)

 

Comments?

 

Thanks

Göran

 

 

From: Lake <[e-mail] <mailto:[e-mail]> > on behalf of Sipos, Brian J. <[e-mail] <mailto:[e-mail]> >
Date: Monday, 20 February 2023 at 23:17
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: [Lake] EDHOC negotiation and errors

Hello,

I’ve been a long-time user of COSE and more recently have been investigating the use of EDHOC as a means of key agreement over long- and variable-delay links. It seems to be quite a good fit to cover the same capabilities of IPsec IKE and DTLS handshake in a transport-agnostic way. One part that seems to be missing is a standard way for EDHOC endpoints to negotiate credential contents.

 

My use case would be optimized if there was a way for an endpoint to include in the ID_CRED_x an “x5t” parameter by default for terseness with known peers but be able to have the peer signal back an “unknown credential referenced” error so that the ID_CRED_x could instead be sent with an entire “x5chain” which would then be cached on the peer. The distinction here is “unknown credential referenced” meaning the peer doesn’t have the credential versus “invalid credential type” meaning the peer can’t handle the given type (KID vs. x5t vs. x5u, etc.). The reason for this kind of negotiation is that the x5t ID would be significantly smaller than the full x5chain.

 

I don’t see any earlier mailing list discussion on this topic and there’s no private use or experimental range reserved for the error code registry, so I don’t see any way of communicating these types of negotiation in an interoperable way. Obviously a follow-on document could make these kinds of error code allocations with accompanying logic, but this seems like a ‘typical’ use case for EDHOC on an open network.

Any thoughts?

 

Brian S.