Subject: [Iotops] Error categories in constrained IoT authentication

From: Göran Selander <[email-masked]>
Date: Mon, 15 Feb 2021 16:53:44 +0000

Hello IOTOPS,

There is a discussion in the LAKE WG regarding the potential need to standardize error messages appearing in a security handshake protocol targeting IoT devices. Is this something IOTOPS could contribute to and/or review?

Assuming this might be the case, here is a background and some draft error categories for discussion.

Background: 
---
LAKE is specifying a lightweight authenticated Diffie-Hellman exchange called EDHOC [1] similar to the TLS 1.3 handshake but targeting constrained IoT. The protocol consists of 3 messages and an error message which may be sent in response to any non-error message. The error message essentially consists of a diagnostic message field containing a text string targeting the peer administrator.

All errors are fatal and cause the protocol to discontinue. The intent with the error message is to provide a hint about the error to the peer application, to enable logging of errors and appropriate management operations. (Note that since the protocol failed to establish security the error message is unprotected and needs to be treated accordingly.)

The question is what error messages need to be standardized, if any.

Detailed information can be provided by using the diagnostic text string. But standardizing detailed error information adds complexity to the specification and implementation, which would contradict one of the design objectives. But perhaps we can we identify a small set of error categories (codes) that require to be singled out, for example because how they impact operations. Such categories could potentially be complemented with text providing additional details.

Please find below a first sketch of error categories (inspired by error alerts from TLS 1.3 [2]).  

Two questions (going in opposite directions):

1. Do we need to make more distinctions/are there missing error categories? 
2. Are these distinctions necessary, or can we remove/group together some of them? 

Draft error categories:
---
A. message field error (syntax error or incorrect protocol field)

B. integrity error (unable to correctly verify a signature or a MAC)

C. credential error (error related to the attempt to use a certificate/raw public key as a basis for autentication, e.g., certificate expired, revoked, unsupported, corrupt, unknown CA etc.)

D. access denied (credential valid but peer not allowed access)

E. internal error (error not related to the protocol or the peer)

F. auxiliary data error (unsupported or missing extension)

G. cipher suite not supported (this particular error has already been specified with a special message field, see Section 6)

Any comments are welcome.

Thanks
Göran

[1] https://tools.ietf.org/html/draft-ietf-lake-edhoc
[2] https://tools.ietf.org/html/rfc8446#section-6.2

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Feb 2021 12:19:44 -0500

> There is a discussion in the LAKE WG regarding the potential need to
    > standardize error messages appearing in a security handshake protocol
    > targeting IoT devices. Is this something IOTOPS could contribute to
    > and/or review?

Maybe.

    > Background:
    > ---
    > LAKE is specifying a lightweight authenticated Diffie-Hellman exchange
    > called EDHOC [1] similar to the TLS 1.3 handshake but targeting
    > constrained IoT. The protocol consists of 3 messages and an error
    > message which may be sent in response to any non-error message. The
    > error message essentially consists of a diagnostic message field
    > containing a text string targeting the peer administrator.

    > All errors are fatal and cause the protocol to discontinue. The intent
    > with the error message is to provide a hint about the error to the peer
    > application, to enable logging of errors and appropriate management
    > operations. (Note that since the protocol failed to establish security
    > the error message is unprotected and needs to be treated accordingly.)

    > Detailed information can be provided by using the diagnostic text
    > string. But standardizing detailed error information adds complexity to
    > the specification and implementation, which would contradict one of the
    > design objectives. But perhaps we can we identify a small set of error
    > categories (codes) that require to be singled out, for example because
    > how they impact operations. Such categories could potentially be
    > complemented with text providing additional details.

I am imaging that the resulting error codes are not just sent to the peer,
but might be link-local multicast. They *could* be object signed by the sending device!
It is pretty clear how to do cheap multicast over wired and 802.11, but what
multicast means over an route-over LLN-mesh remains to be determined: it's
not free.

Consider the situation of being able to plug a diagnostic device into the
home LAN, and be able to find out what devices are failing in what way.

Significant privacy risk, for sure.
There could be some kind of blind applied so that the devices are not
immediately recognizable.
That could be as easy as just not including a strong identity.

But, security which fails in ways nobody can diagnose, is security that gets turned off.

I think that there is a sweet spot where we could get enough information to
do further investigation, while not blasting useless information around.

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

---

From: Göran Selander <[email-masked]>
Date: Tue, 16 Feb 2021 07:39:03 +0000

Hi Michael, and all,

On 2021-02-15, 18:20, "Iotops on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    Maybe.

[GS] Thanks for the consideration. I now realize this sounded like a formal request to the WG, but it was intended to just probe if anyone has an opinion and wanted to share some thoughts.

[GS] Exactly this was the intent with the draft error categories A-G in my previous mail. Are they doing a good job?

Göran

---

From: Esko Dijk <[email-masked]>
Date: Tue, 16 Feb 2021 08:31:53 +0000

Hi Göran,

Thanks; this demonstrates the added value of Iotops :-)   Without your message I wouldn't even have known that LAKE is doing this! The error codes would be very useful for other bootstrap protocols as well, like BRSKI and constrained BRSKI also being developed now (ANIMA WG). The current status reporting uses a JSON resp. CBOR message with a machine-readable Boolean 'success' essentially, which could be easily augmented with a standardized error code field. Note that in this case the status report is sent within a secure DTLS session. 
I don't have detailed feedback yet on the categories but these things are to be considered:

1.  the error code needs to be encoded as an unsigned integer value - it should get a symbolic label also like in (D)TLS, linked to an integer value, to make code and specs better readable.
2. reserve one of the status codes for success, so that the status reporting can also use the standard value in case of no error
3. to avoid complexity, allow implementations to use a high-level code with not too much detail. For those implementations that can afford to add more complex/detailed diagnostics, use sub-codes.  Then in the future potentially even a 3rd level of diagnostic info could be added. In CBOR this can be easily encoded e.g. as uint only for a single error code, or an array [code1, code2] for the more detailed information codes. Good thing is that the second-level etc. error codes could be standardized also later on, on a need basis.

And one security consideration just to keep in mind: too much detail in the error reporting is not good if it reveals information that an attacker can use to do a next, more targeted attack.
The HTTP/CoAP, Netconf, or (D)TLS error definitions could indeed provide some inspiration on what to include.
I found also an example of an error code registry here: https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#error-codes  this kind of registry could be used to keep track of the codes and any extensions to it.

Best regards
Esko Dijk

IoTconsultancy.nl  |  Email/Teams: [email-masked] 

-----Original Message-----
From: Iotops <[email-masked]> On Behalf Of Göran Selander
Sent: Tuesday, February 16, 2021 08:39
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Iotops] Error categories in constrained IoT authentication

Hi Michael, and all,

    Maybe.

Göran

-- 
Iotops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iotops

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Feb 2021 12:30:36 -0500

Göran Selander <[email-masked]> wrote:
    mcr>     I think that there is a sweet spot where we could get enough
    mcr> information to do further investigation, while not blasting useless
    mcr> information around.

    GS> Exactly this was the intent with the draft error categories A-G in my
    GS> previous mail. Are they doing a good job?

They get close, but they only describe complete failures, and they may need
to announce intermediate progress, or even failures to even begin.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Feb 2021 12:13:06 -0500

Esko Dijk <[email-masked]> wrote:
    > And one security consideration just to keep in mind: too much detail in
    > the error reporting is not good if it reveals information that an
    > attacker can use to do a next, more targeted attack.

Too little is useless.
I think that you explained it very well, and perhaps we can call this the
"Law of Dijk" in the future :-)

    > The HTTP/CoAP,
    > Netconf, or (D)TLS error definitions could indeed provide some
    > inspiration on what to include.  I found also an example of an error
    > code registry here:
    > https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#error-codes
    > this kind of registry could be used to keep track of the codes and any
    > extensions to it.

How do you feel about non-failures, like, "I am trying to do X, but I am
timing out. I am still trying"

---

From: Göran Selander <[email-masked]>
Date: Tue, 23 Feb 2021 11:07:29 +0000

Hi Esko, and all,

Thanks for good input! Comments inline.

On 2021-02-16, 09:32, "Iotops on behalf of Esko Dijk" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Göran,

    Thanks; this demonstrates the added value of Iotops :-)   Without your message I wouldn't even have known that LAKE is doing this! 

[GS] Most of LAKE discussion takes place in Github and meetings. Here is a recent issue on this topic: 
https://github.com/lake-wg/edhoc/issues/74

The error codes would be very useful for other bootstrap protocols as well, like BRSKI and constrained BRSKI also being developed now (ANIMA WG). The current status reporting uses a JSON resp. CBOR message with a machine-readable Boolean 'success' essentially, which could be easily augmented with a standardized error code field. Note that in this case the status report is sent within a secure DTLS session. 

[GS] Yes, CBOR integer encoding is aligned with the current thinking, and it makes sense to give each category a symbolic label.

[GS] Not sure EDHOC has use for success codes by the nature of the protocol, but there should be sufficient number of 1-byte CBOR integers to reserve one for this.

[GS] Good idea. This in combination with an IANA registry allows for extensibility. We would still need to get the top level categories right, but we could at least be less worried about e.g. which sub-categories of "credential error" we need to specify initially.  Related question: For the error message in EDHOC there is currently an optional text string intended for diagnostic message to be logged and read by an administrator of the peer. Assuming we will use error coding as discussed here, does such an application specified text string add any significant value?

[GS] Exactly. This is why we try to understand which error messages really need to be sent. For certain errors the processing should just stop and no error message be sent. For others there may be a need to express things like "X went wrong" or  "my fault", to enable resending. Some intuition about the bare minimum needed here is most welcome!

[GS] Reflecting over this and the different settings I made a revised list of categories, see below.
 I can see the difference between the case when security is already established and the case before/during authentication which LAKE is looking at. In particular category C, credential error, didn't make sense to me in the case where security is already established. But there are also intermediate cases, like when a single COSE object is sent which involves using credentials to derive keys used to unprotect the message, and potential error messages in that process. Here are five categories: 

A. message field error (syntax error or incorrect protocol field, unsupported or missing extension = former category F). The ALTO error codes could fit into some subcategory here.

C. credential error (error related to the attempt to use a certificate/raw public key as a basis for authentication,  credential expired, revoked, unsupported, corrupt, unknown authority, cipher suite not supported = former category G)

D. access denied (credential/key valid but peer not allowed access)

E. internal error (error not related to the protocol/message or the peer)

Is this going in the right direction? Other comments?

Thanks
Göran

    -----Original Message-----
    From: Iotops <[email-masked]> On Behalf Of Göran Selander
    Sent: Tuesday, February 16, 2021 08:39
    To: Michael Richardson <[email-masked]>; [email-masked]
    Subject: Re: [Iotops] Error categories in constrained IoT authentication

    Hi Michael, and all,

        Maybe.

    Göran

---

From: Göran Selander <[email-masked]>
Date: Tue, 23 Feb 2021 11:08:10 +0000

Thanks Michael, a question below.

On 2021-02-16, 18:30, "Michael Richardson" <[email-masked]> wrote:

    mcr> They get close, but they only describe complete failures, and they may need
    mcr> to announce intermediate progress, or even failures to even begin.

[GS]  Could you give some example of "failure to begin", and "announce intermediate progress" which illustrates missing top level categories? 

* I can see that category D (access denied, credential valid but peer not allowed access) -  is announcing intermediate progress since it denies error of category C (credential error). 

* Intermediate progress could also be incorporated in sub-categories. For example, if we define :

A.1 Syntax error
A.2 Incorrect protocol field.

then A.2 indicates intermediate progress because to be able to determine incorrect protocol field at least some part of syntax needs to be correct.

Thanks 
Göran

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Feb 2021 17:04:47 +0100

Hi Göran

I’m thinking that there are some errors that are ok and some that should remain generic, given that the message is transmitted in the clear.  CoAP-style error messages seem reasonable.

Eliot

> On 23 Feb 2021, at 12:08, Göran Selander <goran.selander=[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Feb 2021 13:41:46 -0500

mcr> They get close, but they only describe complete failures, and they
    mcr> may need to announce intermediate progress, or even failures to even
    mcr> begin.

    GS> Could you give some example of "failure to begin", and "announce
    GS> intermediate progress" which illustrates missing top level
    GS> categories?

failure to begin:

In a BRSKI situation: device has not begun onboarding because it never found a join proxy.

In some other onboarding situation, it could be that device is waiting to see
some other broadcast.  Or perhaps it needs an IPv4 address, or an answer to a
DNS request.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Feb 2021 01:35:00 +0100

Some thoughts:

a) i haven't seen anything in the ask that i would consider IoT specific, but then
   again, i am not sure what IoT is. As in: unless someone suggests a better WG this is
   IMHO a great topic to discuss if not work on.

b) I think it would be worthwhile to write up generic guidance to design diagnostics in the
   face of security. I hrve seen this done wrong, although my last vivid memories are from
   non-iot use cases (systems that tried hard to do everything wrong that could be done
   wrong in username/password authentication).

c) best diagnostic requires IMHO operational experience. What does help are ways to create
   more agile mechanisms than writing a spec. For example creating a registry to which things
   can be added applying and extending existing RFCs. (a bit different form of a registry
   than the typical IANA ones). That might help for diagnostics to evolve more agile.

d) Some class of diagnostics that really helps the good guys may help the bad guys, but they
   still need brute force. Slowing down things can be the tool to permit the good diagnostics
   while still hurting the bad guys.

e) For IoT specific i would certainly appreciate a complete formal distinction of
   error codes. Sending some generic "0x999 (random error) and detailling what actually
   happens in text field afterwards works for "Simple Classical Human Protocol", but not (IMHO)
   for IoT.

f) One maybe useful criteria to coalesce diagnostics into as few as possible different ones
   is to ask: whats the difference in actionable next steps. If there is no difference then
   likely those different diagnostics could be one.

g) In one common case a device might give an error 
   0x7411 Only my admin can help, ticket #345687

   As in: the other side observing this error really can only refer to the (unique)
   ticket id and tell that to he admin of the reporting device. For various reasons
   Many of which likely are embarassing to the admin of the device ;-)

  Aka local ticketing of error events is another common scheme for diagnostics.

Cheers
    Toerless

---

From: Göran Selander <[email-masked]>
Date: Thu, 25 Feb 2021 15:52:03 +0000

Thanks Eliot!

I agree that information about the error needs to be restricted since the message is sent in clear. Since there is no secure communication in place yet, a handshake protocol already reveals some information and allows in many cases an eavesdropper to infer that the protocol has failed just by following the message flow. Depending on where in the message flow the protocol fails also reveals candidate reasons why the protocol failed. So an explicit error messages does not necessarily leak much more additional information and can remove unnecessary overhead due to resending of protocol messages which each time fail for the same reason. (The peer should also beware that error messages may spoofed. Spoofing may be used as denial of service, but this is just one out of several ways to interrupt the protocol.)

EDHOC is expected to be transported over CoAP or other protocol providing the same reliability properties, so the kind of error message related to e.g. ordering, message duplication etc. is not in scope. But the same style of errors could be considered. I like the idea of categories and sub-categories that can be refined which Esko mentioned. But for a handshake protocol it may be relevant to use both top-level category messages and certain specific sub-categories.

Just to give a concrete example, is it necessary for a constrained IoT handshake protocol to distinguish between "certificate revoked", "certificate expired" and "CA unknown". Or is "credential error" the right level?

Thanks,
Göran

On 2021-02-23, 17:05, "Eliot Lear" <lear=[email-masked]> wrote:

    Hi Göran

    Eliot

---

From: Göran Selander <[email-masked]>
Date: Thu, 25 Feb 2021 15:52:07 +0000

Hi Toerless,

Thanks for detailed input, very helpful! Comments inline.

On 2021-02-24, 01:35, "Toerless Eckert" <[email-masked]> wrote:

    Some thoughts:

    a) i haven't seen anything in the ask that i would consider IoT specific, but then
       again, i am not sure what IoT is.

[GS] I can understand reluctance using the general IoT concept. For LAKE there is the notion of "constrained IoT" outlined in [1] with requirements on security, low complexity and low overhead.

 As in: unless someone suggests a better WG this is
       IMHO a great topic to discuss if not work on.

[GS] Thanks for encouragement!

    c) best diagnostic requires IMHO operational experience. 

[GS] which is why we turned to this WG :-)

      What does help are ways to create
       more agile mechanisms than writing a spec. For example creating a registry to which things
       can be added applying and extending existing RFCs. (a bit different form of a registry
       than the typical IANA ones). That might help for diagnostics to evolve more agile.

[GS] I'd like to understand exactly what is missing part in current registration policies for IANA registries. Say we specify some generic code points which may be relevant for many applications. Then specific industries could request complementing code points with reference to their specification, if available, or just expert review. Closed ecosystems could use private ranges as they like. What would need to change to make things sufficiently flexible? 

[GS] I didn't understand this, could you please elaborate?

[GS] OK I see the problem, but also for constrained IoT deployments may errors require human intervention.  (For example, how to handle to "unknown CA"?) And for the case when there is a human in the loop then the optional text string makes sense.

[GS] This is exactly the mindset! We start with a set of categories and then ask the question: Do we really need to distinguish each of these categories, or do we need others - what is the difference in actions? We started thinking about this in the context of the categories mentioned previously:
A. Message field error
B. Integrity error
C. Credential error
D. Access denied
E. Internal error.
I think it is favorable to be able to distinguish between external error (A-D) and internal error (E) because in case of E just waiting for the message to be resent may actually solve the problem. C and D (which may be viewed as a subcategory of C in the sense of no relevant credential available) seems also valuable to get informed about, since that typically will not sort itself out so there is no point in resending the same message again. Do we need to distinguish between non-security error (A) and security error (B-D), or single out that the MAC/signature failed (B)?

[GS] Nice example, wouldn't it fit into the model with high-level error type and optional text string?

Thanks,
Göran

[1] https://tools.ietf.org/html/draft-ietf-lake-reqs-04

    Cheers
        Toerless

---

From: Göran Selander <[email-masked]>
Date: Thu, 25 Feb 2021 16:25:17 +0000

Thanks Michael,

On 2021-02-23, 19:41, "Michael Richardson" <[email-masked]> wrote:

    mcr> failure to begin:
    mcr> In a BRSKI situation: device has not begun onboarding because it never found a join proxy.
    mcr> In some other onboarding situation, it could be that device is waiting to see
    mcr> some other broadcast.  Or perhaps it needs an IPv4 address, or an answer to a
    mcr> DNS request.

I'm trying to map to things that has to do with the handshake protocol. These examples seems to be quite specific onboarding issues, and not clear to me how what top level category they represent. Perhaps driving the analogy too far.

Thanks
Göran