[Iotops] Error categories in constrained IoT authentication

[Göran Selander <[e-mail]>]

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