Re: [Iotops] Error categories in constrained IoT authentication

[Toerless Eckert <[e-mail]>]

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

On Mon, Feb 15, 2021 at 04:53:44PM +0000, G?ran Selander wrote:
> 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
> 
> 
> 
> -- 
> Iotops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iotops