Re: [Iotops] Error categories in constrained IoT authentication

Göran Selander <goran.selander@ericsson.com> Tue, 23 February 2021 11:07 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B03A1337 for <iotops@ietfa.amsl.com>; Tue, 23 Feb 2021 03:07:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.671
X-Spam-Level:
X-Spam-Status: No, score=-7.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAg78zotfg_E for <iotops@ietfa.amsl.com>; Tue, 23 Feb 2021 03:07:41 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10058.outbound.protection.outlook.com [40.107.1.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0AD23A12E4 for <iotops@ietf.org>; Tue, 23 Feb 2021 03:07:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=abdMuF1346YUQ4et1DjUBl2IxEc+5+ZptL0a2zw5pQeH680khNC6oUiECjpThJZzbvrGH9Fji810EA/rifrjdBjlPd3HjrI2t1ftM4GfkA0KgDsyuzk3l/KBqSe7Iks+37gNgx4e129tD91EATCzQ9L33LaHkF61wLYl3Fpr686KWtUxZMDqgidydzN3kT3HQXNmmabcCT84lvIGmUkkOapuTBCouISe2SKoWZSFoUuZ5M00G3ZvSSuhwxDb3RlMy4Rfb3xpMtk8qluqR9dqeXEbFIeCw0shS2ule7ayj0LK3ivbANehDlPEWqA3C1UuC1AC3csV4Sg6ME9feOUeZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kVf5sEX4IpXFXaO/wcvOvG+EdC1BGDqC11QExMozUHY=; b=PSUUvRQ6rWW3xdvopsG5P5hAsQvsmwfYwnq2HbT11a+BisaCItRwc1++OVVfSN4lRNcTJ7tQcFxAUUaDjF2VrPm3ha4R12PYm0i187jB94cQHJjL1sH3SlaRlrxRb0oXCeMMv4L7NYfrE9exEysvuKORt8fytOoRpLFAihLcDfgaUJ0uX4zjiT5JffnZqs8OInJUc2+Vtm5JtAR1xdRqiGzf09CDjE8/U+RlAcF8ZpoaqD4HDXxAS//6xK3QTcYNyiHTaOi0ppixXFUXgIFFrbdfSXa3C+p6lefpBnG43aDdq/zPnXVJwYVJQWwqdpQNQDGlet4ph0VmnR0aaK3Cwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kVf5sEX4IpXFXaO/wcvOvG+EdC1BGDqC11QExMozUHY=; b=Q3paIn4/BSNihQA5yBqWc7JU7fgp1NVgwb1/9N99fzlYsbHdKMBGTJUQOezsPI+XlknthBe7ShwrUvS2mj5AOFrzPjXYXvjrQ/H/YlDUWW6QI33plZI1ruDq+T2qNBG5jpc4WAnb/1mFyFjpDUW2/QG6hhoBmkU4HLkR2XEyxB8=
Received: from (2603:10a6:7:82::14) by HE1PR0702MB3609.eurprd07.prod.outlook.com (2603:10a6:7:83::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.13; Tue, 23 Feb 2021 11:07:29 +0000
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::588f:43b1:d981:5bc8]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::588f:43b1:d981:5bc8%5]) with mapi id 15.20.3846.045; Tue, 23 Feb 2021 11:07:29 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: [Iotops] Error categories in constrained IoT authentication
Thread-Index: AQHXA7sevPYsVE9D80KdsgQDTgiUsqpZdgoAgAEA24D///fKEIALQsMA
Date: Tue, 23 Feb 2021 11:07:29 +0000
Message-ID: <858BC89D-18B4-49D3-904A-132F13BB4EA8@ericsson.com>
References: <49569FF2-938B-4584-B290-F16558F352F5@ericsson.com> <27125.1613409584@localhost> <7FFB63D7-801D-4E8B-8257-BE9BCF7BA6BF@ericsson.com> <AM8P190MB0979BF8094F05FDD52B491ADFD879@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P190MB0979BF8094F05FDD52B491ADFD879@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21021600
authentication-results: iotconsultancy.nl; dkim=none (message not signed) header.d=none;iotconsultancy.nl; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.249.67.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a0ba1ba0-feb9-4c7e-4b6c-08d8d7eb35f8
x-ms-traffictypediagnostic: HE1PR0702MB3609:
x-microsoft-antispam-prvs: <HE1PR0702MB360971550AE08B734C415D02F4809@HE1PR0702MB3609.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8/LnLARfoletXmhT4pfSTypH8b/f7Kgboy3SXFUQXOvWD6G9GrxjObKwR8N6IbxEr/JbRorqEQObV0qP4bBmTMEWpz4H+fivugbHLbApqJC3ibLmTIPjpZiRCKpVWoA3jtNgJo/RLRV5b3ZegwAPMS3g7FAhIhvzw9ZNnEENtypBeRpuOIXMOLtJToVaYo0jZS6iMlBMjx2GUDPzERb/X86H30cVPRbXEYDTSn/AKrybkCuhZT4d1a43+uk3iiFDzbfXPmqTkuWguHk/ajQul4hzHxgvreDaq0liTat7gZfSZWswuVELmDEQqz3nYE+J792boCFkZznEl/60Xt1z7ykxVNl/jzObWLs0Wfz6MFgqRFsrLzJVqFWKA4BtV9iOV2LDaJguQS0FJnckQQ6a5CnoFYyYONWzOrLRm6B+abktAZRLl8kgxlRXV+KKJeATXi6D4trspXA4ki+XsIGwXNtmY7PuIS6ROUncYqv4Nnia9DcZDIF64hTZvtdgs8beaIS50Xn+uGf9FpY4BrVftvX+5RlKXh3PwF4Vq2gy7EZWvhTXJKf0NdVPg47IHx6jlKb36QjGz8XSGsYuAci3ux8NVaqzZCl3Y17zml5E8Po+jS8WeE6nT9jIxGzeo2Z8kYdiI+vqyOHe5olOFdjS4Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(966005)(66476007)(66574015)(36756003)(66446008)(8936002)(66556008)(86362001)(6486002)(83380400001)(316002)(6506007)(33656002)(64756008)(2906002)(8676002)(6512007)(478600001)(85202003)(71200400001)(186003)(66946007)(110136005)(26005)(76116006)(2616005)(5660300002)(53546011)(85182001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: rhqpMDcn+M+8okUcs9R2OZwk2yb+CChAHE1k01hoja9VD0OWu1HiK+WCptLdBlmN12CwtEDiWKiOmBQIUncQ4uMidXFkyBIGdMLJ3/v/LscqhGNwXnepGuH6HAYMSHUn40veyiCRb71KadMVlicsEM8tCfWsLGuxV/C4unhZK9eGSxkKLLklJeQ8lAY467pW0D7twv5WmMUhA5mACABjfbZ6k8Ggze3aRjc2ajh/cg2aFYSz0xcvgiRJREDScdHm7DjXexpjQSCc8TRgJf9+7MR1AzYAcDODsi5F0vZnoM3pTz7ieBpHm2DEzC9OlTxffLY7Mj84jziCx3hJI+sUthUbAtIsRUpALLTWSkP9IMNmdEyNtDsWE0DwyXWIeaXymLtlSVILuU9BP8oA8eQ0FrBeXrrqxl0aEgw82Xu70VAwD9nOoy7iAN2rhLEnrEgV41qvk5M3S7BL2p+KZ3n7fswdAoIgmdCGfLK5qUi77S80PZZIURVsTjzUtlad5wgFQNN5BeuyvbLPAQygMs/YPs5PrkiO+OOq/t6quGOU/BN/xFYyLXPpDBt2aISRPqEwDcriAiPV/HGM8d1AwriozW9FQ/vel3dv3vEV6HPUT4EOHiaR4iddmApaFrmLLKelBfkCMdL67e2dkzAlDW1zDUvNkbOjZAnlwm/tKVQjh4K8uoyc3UBGXGpaR9mhWxknsFTEqzhUDeojQ2v0OG9jX24lfbT29VcuO3vbuJubtOq3f6E9bYBsE4guVo8+GxW+c3wAtfu+y/9fpjUJn/FuqbOowj58miqif4W7AaxuGm8b7k0/2MLS/0iJKgr3tacDR41QjhLTewSATeazAwSlDc4s8vmVDPj7Y3OtZsdikFoE5X2DUuwGkEgQCkLT7d+YFFAbzTRMjaIBqvssfh4x9xDbIvOqjfH9ImyyVPyzPki/a/+TNfXhxZKtkkhvg8gUA2Uw+/7aDXAtVn55pBIlBWNPojubkC0QBAu+0j2Ihq4MAJ9jczxt+CaBDjJ0P49kClgcTtPa7QjD3IUk736NTYXcUQdGntxhl14cqhpcRjOyMZ7Z+qZCx3rxlg7XHOCYKJY39vmdzj+KE6+E1j8UpVsc2E3fdPLmk7ra/yOZhtH+chzukKxRum8rP2jkeE/jJsPCg7+tckEY1LozP8tuO42D0k0Khi5YOnFl8Kk6hBOJnn6AkB2kUfa+PBK5QGqaEoFaRMMelsXA7vl6/QGbzOlZAtArW3wKMhhMKZw4LcwtEwSlAhdZ4YWk7DejaWL6WD+0ZyTJuDVPXNp2jAON05Y2KFnfBJKBEGmob7zx6jtsdWAbSr/nbg8IcBBfid7I
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <5C8AA5C5CA7AB44EBA53DC73622AF030@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a0ba1ba0-feb9-4c7e-4b6c-08d8d7eb35f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 11:07:29.4706 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ep8NBInrbjXeM8G6zA0sWKkessklQB53kGRspbVYP+yEhGyh+fQRPMaa4Zef/Juy/ZerUxyKnqX4QiXtIDpbAaZQZFQql9pvmlGrx5Rb3tQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3609
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/-N1iCxfppn0cOhpQN-X2F5sXbqY>
Subject: Re: [Iotops] Error categories in constrained IoT authentication
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2021 11:07:43 -0000

Hi Esko, and all,

Thanks for good input! Comments inline.

On 2021-02-16, 09:32, "Iotops on behalf of Esko Dijk" <iotops-bounces@ietf.org on behalf of esko.dijk@iotconsultancy.nl> 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. 

    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.

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

    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

[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.

    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.

[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?

    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.

[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!

    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.

[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.

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 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 <iotops-bounces@ietf.org> On Behalf Of Göran Selander
    Sent: Tuesday, February 16, 2021 08:39
    To: Michael Richardson <mcr+ietf@sandelman.ca>; iotops@ietf.org
    Subject: Re: [Iotops] Error categories in constrained IoT authentication

    Hi Michael, and all,

    On 2021-02-15, 18:20, "Iotops on behalf of Michael Richardson" <iotops-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:


        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?

        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.

            > 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.

        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.

    [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



    -- 
    Iotops mailing list
    Iotops@ietf.org
    https://www.ietf.org/mailman/listinfo/iotops
    -- 
    Iotops mailing list
    Iotops@ietf.org
    https://www.ietf.org/mailman/listinfo/iotops