Re: [Iotops] Error categories in constrained IoT authentication

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

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=[e-mail]> wrote:

    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=[e-mail]> wrote:
    > 
    > Thanks Michael, a question below.
    > 
    > On 2021-02-16, 18:30, "Michael Richardson" <[e-mail]> 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?
    > 
    >    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
    > 
    > --
    > Iotops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/iotops