Re: [Iotops] Error categories in constrained IoT authentication

Göran Selander <goran.selander@ericsson.com> Thu, 25 February 2021 15:52 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 85A713A1B89 for <iotops@ietfa.amsl.com>; Thu, 25 Feb 2021 07:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.671
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 Jn3d092S30lv for <iotops@ietfa.amsl.com>; Thu, 25 Feb 2021 07:52:11 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50067.outbound.protection.outlook.com [40.107.5.67]) (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 DC1613A1B86 for <iotops@ietf.org>; Thu, 25 Feb 2021 07:52:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GowEAtjoEipxRYMNf9OWpCWgz8mm8Y87Zn2qMapaa/Nm0IAJeHVBWELVd8ybYkuExl+Qf84CJYfYOnGCsLzYkwc36IVf9foOslmezrhtPDuhcdt1CxWh6oUgNRZ87FuVf2DaEe2wg6SxIVwbVq1tVnqkibrTFO86PlADrMntVr4MPSxALeX121o7QMLfyYKntkRCUBfmwc6Pd7fmmRjIIsINSxa862PRySn66oeaZDfvakdihOpQENjB2mILoAf+9Ga8cFEdJU3Di2CR7dcxilyA90Ppy7yUN+tIw1vt9GBPR+QxmuMhZcJKLOKbY6/Y890dQOYdpHEG/EG8wvrkPw==
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=LnrgwcjrGELSA9juBbSZnMbqdUJIPXvDeWl+cSGhKJE=; b=JAC++9VXaqiiE9VYBVNFmAGkMBa3+qcj4J7i1yJvH0JW/zH97y1/CT/gzuCBbSGhFAND2NH2aGyMn0jcBD0dMsSi34ao46+aGPLr4sXplmBoj8Im4VrdgJuelpUDZyh7pasmk6hNPhqHgzrhmJ25kngkOgeBwJbD5hjVIDNFMwB45wRCsxWPS4DzaJAQFVGaGBx3ytfZxVW2q/dm3JvztsooTdae4i2DqH+g6YLgMwR9UaXx7uVfvWco7i2ZlJ3g0nyeUNAk7nM+gXyici2WlyqrYGE4T6awPuUhDHUxkNcCEUPLAtw4GiQasm4Ae1SkG5q8ysXvYmQhK8cGSJW/9Q==
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=LnrgwcjrGELSA9juBbSZnMbqdUJIPXvDeWl+cSGhKJE=; b=sc/RWiIa+ETyAxByqM4CDPUMgsCZcOTpD0l3wArw75NqzXvhbe31n6gEK6goDPQa5+PU41SI/Y9ZR4BmuyNeJzIjKLud41349qaJGy5vPIcCSP/bWpLEoyBUeqtclYj+hZQ+4ojoI5TIE8Y6Ghyc3ZZ2IYBu+xrjKOEQgL9CMu8=
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB3065.eurprd07.prod.outlook.com (2603:10a6:7:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.20; Thu, 25 Feb 2021 15:52:07 +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; Thu, 25 Feb 2021 15:52:07 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: [Iotops] Error categories in constrained IoT authentication
Thread-Index: AQHXA7sevPYsVE9D80KdsgQDTgiUsqpmgk4AgAKjVAA=
Date: Thu, 25 Feb 2021 15:52:07 +0000
Message-ID: <FC759943-6F48-4406-8E4E-E93D70A921A8@ericsson.com>
References: <49569FF2-938B-4584-B290-F16558F352F5@ericsson.com> <20210224003500.GM35983@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20210224003500.GM35983@faui48f.informatik.uni-erlangen.de>
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: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; 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: be969cd3-25f2-4f90-a543-08d8d9a54dd8
x-ms-traffictypediagnostic: HE1PR07MB3065:
x-ms-exchange-minimumurldomainage: ietf.org#9483
x-microsoft-antispam-prvs: <HE1PR07MB30653E387B816687AC80C4F7F49E9@HE1PR07MB3065.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: VpTDMmFyUUuWBJiB7uTyCB/e4IorcvcAUT0P73b4J3spTdRwycIQGC2C6b9HOjArWmmvVSUP8GkkhlqK4sO1O1qdze5NOc/gNM1xSS0cah70RwpJlsxLvmBSdspbUbHRWBjY3Rn9QAbNLt51O6eXB8yrfDCxQmYfChmfL2AcvDXZXYRjne8vtoHqe6zQvJ0Vfn/ERCO8uvAeXsVa77UMSQFPO/ib2Z1ZCHbu1WGwo7HrNb3C2UUT7BqkQNnv0Gd91hViy5Trk92HAO33AAkYaS1WeT/ccpbWia1nBC1Z/WfdmJnloT3MfYz4r2oTldSM2KvazC6nWKsGjT9NR/68E5nzYIuKwOGFJjcv4PIa3ypo7FnEy/2/cshFX9+gXaqmxj1JEQ5KTN9kWjhDcV2wtt0DpJWtlVJ8D57k/SbBcesKGr+se/AIib0cOPlvBFQ3Ksl1pzrjNgsobv6CR4n8CGCKfXvvpbg3Jvl7vlhBjbwKo1mwdUOCntSg4BZlDO6TSXPY0q1Y0AhF2ge1TLLwPRmJ/ANt4Yxm3ized9dKVy0vTneOYvZLVJlxqT8jmFY/rFJqcT01gpiI93dCNYacb4vDZhFwc+mtTc3eTfxs2BXiIreaH/6ZiHcQnStBfXr00uKnul8sVgP/6rjxb009Cw==
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)(366004)(346002)(376002)(396003)(39860400002)(136003)(6916009)(316002)(2616005)(66476007)(66556008)(2906002)(8676002)(36756003)(66946007)(76116006)(5660300002)(66446008)(64756008)(26005)(33656002)(86362001)(6486002)(6506007)(71200400001)(85202003)(186003)(4326008)(6512007)(8936002)(966005)(66574015)(478600001)(85182001)(83380400001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?eE5GV2xWcEJUSlQ1STBjb2NyZXVhVDJCR0l6NXFEWEZONHplZWNORXlXZW94?= =?utf-8?B?TDBVRDlaWmV4Q3ZJNmtlQk1SR1VpN2NWZm42d0NJWUk4VEI4L2NGSEtNQ0Jr?= =?utf-8?B?bUlSV0RZSGJFU1pTRzY5OEYrL2FBUmFGWmQ5dDZwSndFUSsxWE01UmlJUGVC?= =?utf-8?B?Y2hLV1B1ZW1ITDJKQnZpSHhQLyt0eG03aUFFdjc3MCs1bFl2V1hPSGtvcjZo?= =?utf-8?B?Q3dxWkRJa0FxWlRoT0NWK1lEdU1rQmFxZm9uK2kvZE5BODVmb1JiUnF5VnBP?= =?utf-8?B?TG1lTlZkZ1gxa2tRSUo4ZGhESlpQYnpzU0NxVTE4bUtERFFIUHFtMUFRQXcr?= =?utf-8?B?YURyS203UmxHdWdjSXY5OUdmUDUrdHJyV2o4ekN2eGVybExiY051M2FjZ3ZX?= =?utf-8?B?VlJpVjdrbEduemZZdUd4UStZUDZVb0VRSTFNZW5BdFhObG8zZHQ2YkV6T1Ay?= =?utf-8?B?Mk8zTExLNVhweTlUWHQzU3E4ODB3RUJBY2FYUGNLTWx1SmxycnNhalRQbG5I?= =?utf-8?B?bzAyeHVueVhjZkVub1VmdWtGRnVUQ042c0xWWVFIeXl2b3E2YkIzR2VQeXZ1?= =?utf-8?B?S1ZHNDJQKzNqWC96VVRLekd5LzVmd29IRnNWWXVsdXRTVlNydWdMNEZIcnJu?= =?utf-8?B?K1AvRDNtMzNqa1FzamZEbW1SeGJsNS82bTIrQ3pPSkV5WnlOUUcrVUxuQXBD?= =?utf-8?B?enN4OEhUR1pja2xsMUxhMWFtZ0ZUNUFycTlreXRhT09lN1RxTjU1SElwUith?= =?utf-8?B?OHJ3aE0yeUcxNTV4cGJ4eDd4dGw2bHNGZHhCN01YOEZMZnE1ZWdjaXR4bW1p?= =?utf-8?B?bDBEankwVGVacDhZaWRxMXQ0akNnZVFlM2Q5ZGQ1TjN3Z3ZGekM4di9yM0ph?= =?utf-8?B?ZWptbGYxQzEvQURIT2pBOFNSam01Tk42VWM4bjdUb0M0OUtRZTRxbG9pWjM1?= =?utf-8?B?UG11bjhISndyU2hWZVpkMC9XdkVDcktlTGJQaHI3MTBJSmZTVXc2MVl2SmIz?= =?utf-8?B?QlRmSDN5ZlYrODdaWEZUOVMzNUtFWE9tam9sZlBFamlqOXh4OFBGb293SE1G?= =?utf-8?B?Q3NMOFROaTdYTXlQcndZd0tHcWplTHVDck1uR24yZklxRmhYbk41L1ZOd1Np?= =?utf-8?B?d3F1ekJvTlhBZUlvU2JNa2ZoblpmdVJNcVFBR1ZWVXdubFJrczBEQ003QkNv?= =?utf-8?B?OHdGNk9pQ0EvSVIrbXBjcWNrL0ZYYjJ6RjBHUmVpQVNxUmc3WjY2OVFjelY2?= =?utf-8?B?a0M2dnFsY3hqM2c5WkF1dGhFM0Z5OFJlRk9CeFJTVGpLdG9XSC9wNWRHdnpD?= =?utf-8?B?M212UklSYXpTaVl6b21WYzR4NFFoYlRFTjlnOU1UcVMzNFV1ZG9zZVRJWk9k?= =?utf-8?B?R0tCcXJnbUhHMXNKcXU4OWttK3pvYjRFZFkrcmpIT0hVeU9DVmp5eHJENnlS?= =?utf-8?B?YzlhY3JDQjJGajI0QjJNSjN5V2VXQjZDOVRsa0orQnJFOHJPSnNiNGxSVHRF?= =?utf-8?B?aFJpNm8xMTErM0kwOXNwR2trY1BMUWpVUlF6cWRFK2pYMVJpMDBYMGF6Rlhj?= =?utf-8?B?bldoVUhQaVpRZGd1WnFBbGsxeDAzaTI2K1VPQnk2MnA2WXpRMkVRcW5EUS9M?= =?utf-8?B?K2FrbFRxR1FsOHp3VjNjUys5Y0QxQUtsQmZMV2NyUmMrSVZFNEV1a3gxYWt5?= =?utf-8?B?eXF0ZHpaV0U2SkRFcVp6REs2NWQ1bW9FeFJpTDhIUXdVMFFSMVB4R09zZ3hD?= =?utf-8?Q?OM+IaY/d//MSd/STHSS8NuLZom0JqprM/gNuWTO?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <910C6253EE2AE54ABAC76DBDCDF27018@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: be969cd3-25f2-4f90-a543-08d8d9a54dd8
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 15:52:07.1000 (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: 8ZN3E4sBfW6YMvquwNbZKJ46xNsJhWoKOvz6TIb/D3u/T+TX47SYJ4HU0Uu3NCEM4UsZaSUWuSxJ5ZreWL8+K3ZlTm9fByHI6sXI/os5MHQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3065
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/Y5K9wR0XgSUi94SdgvWkjB2GJhg>
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: Thu, 25 Feb 2021 15:52:13 -0000

Hi Toerless,

Thanks for detailed input, very helpful! Comments inline.

On 2021-02-24, 01:35, "Toerless Eckert" <tte@cs.fau.de> 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!

    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. 

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

    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.

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

    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.

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

    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.

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

    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.

[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

    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
    > Iotops@ietf.org
    > https://www.ietf.org/mailman/listinfo/iotops

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