Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

John Mattsson <john.mattsson@ericsson.com> Wed, 09 November 2022 14:04 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6803FC1522C4 for <lake@ietfa.amsl.com>; Wed, 9 Nov 2022 06:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.479
X-Spam-Level:
X-Spam-Status: No, score=-7.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_HEX=0.1] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlQqcsVmOk0P for <lake@ietfa.amsl.com>; Wed, 9 Nov 2022 06:04:28 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130044.outbound.protection.outlook.com [40.107.13.44]) (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 35416C1524A5 for <lake@ietf.org>; Wed, 9 Nov 2022 06:04:11 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jSxVc+bBs70h7tk70RkWdMCzxfrLSaaEJMj4fGHi0aK0WN3JUWp+kuTgPcslcNNu5TxCt1loND2jwFFQH1Y9FN4flJgIcvATwo0CYax36jAgOuqRumaBuQH7W99IQcA45VCx8ac3/EwaugFr5omd0LEafYxJRrK77qxNablllxondO7BNYKIQ/D+lauoDlILdUNpAQhP1z4n4YmgDLpY9oX79zZeelJ76OjiSxN1T+TqINW+S3h9QBeElAgiksxD65TnZKlSOiEZTyg3CBlLKgyZRJqkD9+yjCIMqEmAG83vX6V00EYAyMloCrUYlXyj1yMLQfYXzXsM+7q2gvsPzQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ETlwxF2TbEJdHnrZcKVYHv9OlOIWfWA+0f04OKKaC2E=; b=HbnnjhQcRcybYkrZR0T7JIEpEAWpvOw8C2CroJBfC+lF7Amz/nuiMUGLDh/ywGO1GIkurtobFD5uDMDfH8C8xnltt5GS48CjZme2XJ1kwIbNFaWo61ar+yGC3EaBpbFuNmF4cCjTVyAkwftSwmWEV2DqeaQgbiYKK2qOdxdOfdUt3mbJSJoYcYXir+rknv29AnuWSAxRhHCyq/7tjEkB6/trHCtyWqG1gZ1g49Lwx8jZnKHDuKBsehuEnP/28b3bGfphpcEIMFUmXH2MqPCGPabogrQ2Gba9PQqIlfeXNPOPZPyXh7FJ5d11by9yYuHF0j9n84YfLbZcuQh0elnSVw==
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=ETlwxF2TbEJdHnrZcKVYHv9OlOIWfWA+0f04OKKaC2E=; b=X/bGlZSAwV7RZa0oiBSC9heg5ZKZ5LV6ZEUnQouW1/IXZ7oTz688LsqeivxOMpngEUtpnUJNdnfLHbkXWaMpu4j6h+QbNuXeh/PATI34i1j952Wlcf3+OX9+zT849B5FmscPCnP9Bso2sGuSFE3QumdNE8NpcsuXRlhYG07hEh8=
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by GV1PR07MB9071.eurprd07.prod.outlook.com (2603:10a6:150:8a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.25; Wed, 9 Nov 2022 14:04:07 +0000
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4458:48c2:e76a:4057]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4458:48c2:e76a:4057%6]) with mapi id 15.20.5791.027; Wed, 9 Nov 2022 14:04:07 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: David Navarro <david.navarro@ioterop.com>, "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Thread-Index: AQHY74y1uZ8hGkCJuEK1Z3AvnCR//K4ugUlZgAUBVQyAAa25gIABbvPm
Date: Wed, 09 Nov 2022 14:04:07 +0000
Message-ID: <HE1PR0701MB30506904E72704CCBC8A541B893E9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr> <4d31934f-2a26-3392-8511-934e0dbeeb35@inria.fr> <HE1PR0701MB3050E43114D34FCF351A31E0893B9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <HE1PR0701MB3050D59D877EEFF607460963893C9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <PR1P264MB349671BF1EFCD9F9F0B21594E83F9@PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM>
In-Reply-To: <PR1P264MB349671BF1EFCD9F9F0B21594E83F9@PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: HE1PR0701MB3050:EE_|GV1PR07MB9071:EE_
x-ms-office365-filtering-correlation-id: d912d6d4-46bc-437c-2c42-08dac25b449d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gZPB9ofjkiYMWYKr8+3dfjCs28l+y1MVuYEZgjzScC2WXhp5LOHhV/2Ppn46MC8f/pRDQlVjzu8CzbqlEkUi7nJAXr3m0GZHwdG8zp1R6SKbBzq4UhNVYe4yxCP0ptsT7f+IfBzXal8ew3PQVoi17OwnmXfAwpVTDzrnj/T0bwF5KT0kxoJZknTrjPa7+26RP1QxgDjTVydQJsl3nMpwQazWaG9WxSYmG9xZVey09a/UOU/UK+E6rFZ+0wnDWNsnl/UZA+dJSmCU9rK5AjvFBxpDA/1fyJlsljyAhC6dd8SYZUnCQGrBVtMNAR6a900BR855MGMffze2LeZwr3DwpOGwKXsOi+RU1aXhKHwMRUl09H+OPT3U4yZbaidaTU/FwqqtYV327toIO969T0iauBWNXnOUrCh89mfR6p4yoU5djSjuJueDsjlCW57AZ7YSncEpHOGwFYNPS9e4gpPDasjJBUh2+TdY7EldwHGIFOD3CkdzH95DHB3J1dmPO4NmmTxDTB9wqBvE0AgHAasrTPtUaNS8z+QoaWL+QIRaAQaRpRapCgPaZoLyCpSgOc4AL2bzc36R1U3l7OpKKR5BmldQjfJooW5ClojNzWTQE8x7Zjkyw8oMUH67I+RU3JpcokP+9Fhg10nEsPodduWAHz6XjU8w6+h1u84YUPOiLrkgtl8tgFF34xdx1/hrQ1xuqEGBRldcjd+qJqccX2kxLf6x/fFanxjJyRObdMSMAPtUxrHOg+ieVcU3llQGrIpPfcAUMvHHQGRqHdYCxJRpYO94cENLrQmQ/c+Y/Weqeo1eZGLwj+6xjTCa2AAKWWOOHyK8BzPTh+Y5frEMHETkzmYVHTPPezJZ+Lwd3Mj+dXCXXOuVPO5tFpxS7rffdJ9r
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(39860400002)(136003)(346002)(396003)(376002)(366004)(451199015)(1690799008)(83380400001)(38100700002)(86362001)(478600001)(33656002)(8936002)(82960400001)(166002)(41300700001)(966005)(38070700005)(66556008)(76116006)(5660300002)(52536014)(64756008)(316002)(71200400001)(66446008)(91956017)(122000001)(110136005)(26005)(186003)(6506007)(55016003)(66574015)(44832011)(66476007)(9686003)(53546011)(2906002)(7696005)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xvLjuJjKZxUvQO7PsxxOhwXVvhANlE8Vm5sRul6IQaxEI8Ea+/4V5hrnrdusTMoD/ZEStm7cOrDd5pPNEESjWWliifdH3uEBkKiuszB86e53l2M4BTrSIUUtq4OEkodu537mwTDRuziH80m8LijypjLVlaGJ3TMGlkmqSXexoP2AUhzR+itjN2rn7iy3WQQm4NCuDH1Ec0WMlZ05gVDeHQ3NOypfGywKHf7jMBCFszGep8gb8VZi81JwI+BN+dHrUdcmn5Mjc4kms4Kkeke4WWyzs0IkCpmfE11vHFIgG1R3TqygZSU1IEn74avVq/zcELQ77jsyIeYmUVfAQ2YTjO4pF4EfwOaVI6SaCGGdTNldgXoXDH77l+B7QHj93/bEwmYXMo9vIkO7wOpq/o72k3WsbJ2q0GfAplkE4p35crfmGBaFbHqfJVTrascvKLWcxA4co+4j69Wq+miQ6ipoesnrSrHiljRap6Ky987y7MEa5QK8/SdGEbu08oEKhHqDNry6YbISKfjq6iJsNQpFNOXyLe6mkb0ABIQsd7eFfmfJDpfTIKKfq3w3YkRMTAEtqlhAcGxkJG7CITfhrqRpbcKDoB4LqD3fvcGS7t4Cw4sLumvc6ZtpgrgxfkD1eus/zsZfl+cSaUN5rvzNOlYaWho/jra74vPm5UPbzLUFzM76HR6oQ3Sp9GscqZ+ctQcc9tML+EUc+1bMpLmXF8qqM6/6z0M14bVmN0xGYXSOM1y0hioDRq2MFuJa19n0Q1X0OqDPZbE6wYs5lFOL2k4gjqpKpFLPcf9vufh5qWlGt/d3EMM8L6GCBrCQJhdIZAb8c3Dnc54ig/LVb4aVGV3f4kdyk+dgZyz3JvP3WvMIPCbAJLvC/WoxtaZJJWsdjNfYOo8Tx6FXCc79zV0T6TTgrqek8Ym12GdbuILJzIF2ZZSV8DGdss3xi0OvgDBPJsg/P2BjN/q1Izbt8iV0pnP0OeWZ6JV6nbjQbpy/jp+O2gtB+Y/1ZocRnkvyrcB6Q94aYUqsmt3fLEvXNwX5vwLTnGdetHnkHnfhv4d8eLXsCqRrNVNUIYj7E6hdSA63wu4iLoOY/woqNzJcIHYgJ8aQYvJyailThEytNK4r3W5FTSZHqiDN/x/667TqPlHclLFOUZSA/O6hkGjf/CQwmm5psZVOt7pLoEphUHa60ruFEZg1xEhFNnCd/2okTZvAntH/63lH+r8zX5KpatNIhkDJ+nj5kPNm7t6DA6FeE9jTDj7nOWM0EvbrZVfr6H0uoeOJINbEpammEX5BRpyTycovlJTlz/8lF1mldMVkcnNf1mll+CTMJ+EIgS1QS7WVHa+g17Y9GiQYbvW8PXJXJlXpTc207SldaaN3/OmnBCh9x9F3PDDIm3v7mu+bUbaEQ68Z7iReIR4qI6Lcb9qAbubSMJXP3ZnqI8NHLhH25gKZ5IZTy6SIqj8wAsyURaTK7xg8y0FSSjZzQCA6uptQuTT2nZwN1VvFsXnw5U1VmcXlaYYMrd8JefJSS7zJXYzRlDisQD4qOfcnVyfeRs80WOaDNXJyFldKjWN/dZu0TOYE/Vtf7Mugeo8dbG4xNSMQSd9YsG4R3KBkU86MaGQx5tigTBU7MkeWVyZA1KrHufpWhs4=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30506904E72704CCBC8A541B893E9HE1PR0701MB3050_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d912d6d4-46bc-437c-2c42-08dac25b449d
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2022 14:04:07.4997 (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: VAwbKTAU/P2qIF7nyTdx+OdAS0tFiRhLlKQW5dPqJGXOTAILBi/jZnQF0AeVA09r7nMs1e1XNmsZF0Xk9Mxh/fXm9bfNhKGv2HrdH3aEYTg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR07MB9071
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/9rwPxxGX4EcgpACA30ntFuBd0u8>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 14:04:33 -0000

Hi David,

Yes, worries about alleged IPRs regarding point compression have been discussed in IETF in the past. But SEC 1: Elliptic Curve Cryptography version 1 was published over 22 years ago so I would assume that any discussed IPR have expired. Given this, the text about IPR worries should probably have been removed when RFC 8152 (2017) was replaced by RFC 9053 (2022).
https://www.secg.org/SEC1-Ver-1.0.pdf
https://en.wikipedia.org/wiki/ECC_patents

>which is (probably) subject to the same IPR considerations.
I don’t know why you think that? Compact representation is not point compression. Compact representation has been discussed several times in the IETF also in the past. I have not seen any suggestions that there would be alleged IPRs on compact representation.

>Another possibility would be to mandate the usage of the SECG encoding in G_Y and G_X. While this would add an unnecessary byte
I assume you mean the uncompressed format which would add 33 unnecessary bytes. Even a single extra bytes would be very problematic for message_2. LAKE is targeting 45 byte message_2 which is exactly met by the current specification.

John

From: Lake <lake-bounces@ietf.org> on behalf of David Navarro <david.navarro@ioterop.com>
Date: Tuesday, 8 November 2022 at 15:37
To: lake@ietf.org <lake@ietf.org>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Hi,

Sorry for my late comment.

Some background:
SEC 1: Elliptic Curve Cryptography (https://www.secg.org/sec1-v2.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6f46d604960a0442&q=1&e=e6a3dd14-b0bc-4d67-82e8-3a6262137c4c&u=https%3A%2F%2Fwww.secg.org%2Fsec1-v2.pdf>) defines two representations for Elliptic Curve Point of Weierstrass curve families public keys (section 2.3.3):
  - the uncompressed representation: byte 0x04 followed by the X coordinate and the Y coordinate.
  - the compressed representation: byte 0x02 or 0x03 followed by the X coordinate. The value of the first byte depends on the sign of the Y coordinate.

The latter format is not used in TLS for Intellectual Property reasons. The COSE RFC contains the following statement:
"Generally, protocols transmit elliptic-curve points as either the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended by the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful."

draft-ietf-lake-edhoc-17 in Appendix B specifies a compact representation for Elliptic-Curve-Point which is (probably) subject to the same IPR considerations.
Maybe this could be indicated in the text.

Another possibility would be to mandate the usage of the SECG encoding in G_Y and G_X. While this would add an unnecessary byte, it would allow implementation to avoid the IP contamination by using the uncompressed representation.

Regards,
David Navarro

From: Lake <lake-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Monday, 7 November, 2022 14:01
To: Charlie Jacomme <charlie.jacomme@inria.fr>; lake@ietf.org
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Charlie Jacomme wrote:
>and would only be caught on a message 4 or key confirmation.
Just like changes to PAD_2 I think it the changes would be detected when verifying CIPHERTEXT_3

John wrote:
>I assume that someone also theoretically could register a randomized AEAD in
>COSE which would only be EUF-CMA.
My bad, such an AEAD would not pass the IND-CCA game I think.

From: John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>>
Date: Friday, 4 November 2022 at 09:55
To: Charlie Jacomme <charlie.jacomme@inria.fr<mailto:charlie.jacomme@inria.fr>>, lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Hi Charlie,

Good catch, I think we should do some small update so the text is correct. My understanding is that EdDSA (The IETF standard) is SUF-CMA, while ECDSA, RSASSA-PKCS1-v1_5, and RSASSA-PSS are EUF-CMA. I do not know about HSS-LMS.

I assume that someone also theoretically could register a randomized AEAD in COSE which would only be EUF-CMA.

Cheers,
John

From: Lake <lake-bounces@ietf.org<mailto:lake-bounces@ietf.org>> on behalf of Charlie Jacomme <charlie.jacomme@inria.fr<mailto:charlie.jacomme@inria.fr>>
Date: Thursday, 3 November 2022 at 15:01
To: lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Hi all,

Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft.

Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape.

It concerns the following point, page 42:
    "Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2. "

This claim in fact depends on the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk,  there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is not a violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detected after verifying the signature, and would only be caught on a message 4 or key confirmation.

This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while under the stronger SUF-CMA assumption, a signature authenticates both the underlying message and the signature itself.  None of the concrete signature scheme currently standardized appears to be malleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changed or not.

Best,
Charlie Jacomme, Elise Klein, Steve Kremer and Maïwenn Racouchot.
On 14/10/2022 12:24, Mališa Vučinić wrote:
Hi all,

As discussed during the interim on 5 October 2022, this email triggers the working group last call for the version 17 of the EDHOC draft, the main item on the agenda of the LAKE working group.

The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/

Please state your position and comments to the list by 4 November 2022 so we can discuss them during the IETF 115 meeting in London.

Thanks,
Mališa, for the chairs






[ioterop-your-lwm2m-partner]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-69506f61806fcc59&q=1&e=e6a3dd14-b0bc-4d67-82e8-3a6262137c4c&u=https%3A%2F%2Fioterop.com%2F>

[social-icon-linkedin]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-d091a09e01641029&q=1&e=e6a3dd14-b0bc-4d67-82e8-3a6262137c4c&u=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2F7955832%2F>[social-icon-twitter]<https://twitter.com/ioteropcompany>[social-icon-facebook]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5fc289dc1fc746c7&q=1&e=e6a3dd14-b0bc-4d67-82e8-3a6262137c4c&u=https%3A%2F%2Fwww.facebook.com%2FIoteropCompany%2F>