IETF Logo Mail Archive

Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal

Eliot Lear <lear@cisco.com> Wed, 10 July 2019 08:14 UTC

Return-Path: <lear@cisco.com>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3839712018C; Wed, 10 Jul 2019 01:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PXFC2RIdlhyZ; Wed, 10 Jul 2019 01:14:43 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E961200D6; Wed, 10 Jul 2019 01:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5329; q=dns/txt; s=iport; t=1562746482; x=1563956082; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=WREPVnpTWeH84o47JA6ys0Aw4o7PxmEEMD5gmxxFRC8=; b=T6mM7SJeLrgOBADvwUPi5sRd+nnBlMcXqFSg4rqxZhpE6LatxR9pLe+v S7zKA6sa7YmR2TtJK7HaSjVbnrKu9BaphnDrzj9xmq6bUrwM4M9tyqNTR 2HP3mbLBou+AOJAC9QW2xOecT6H5LHYI6XGEXxv1CgOAGg/nJM7Ig+CtE E=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BWAAD2nSVd/xbLJq1mGgEBAQEBAgEBAQEHAgEBAQGBZ4MBUiASKIQciHuLb5J0hyYDVAIHAQEBCQMBARsUAQGEQAKCbjgTAQMBAQQBAQIBBW2FPAyFSwEEASNWBQsLBD4CAlcGgzUBgXsPrgOBMoVHhGEQgTSBUYg7gWqBfxJ/Jx+CTD6ELoMgMoImBJRmlW4JghuCH4EMgyyNLxuDGYoZik6UcYxzgwoCBAYFAhWBZyGBWDMaCBsVZQGCQQk1hXSCbodnPQMwj1MBAQ
X-IronPort-AV: E=Sophos;i="5.63,473,1557187200"; d="asc'?scan'208,217";a="14087066"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jul 2019 08:14:38 +0000
Received: from [10.61.166.105] ([10.61.166.105]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6A8EbwB021041 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jul 2019 08:14:38 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <2708D89A-90CD-41DE-900D-0BFC8AB5B814@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5E4F39DB-41C2-4810-9A71-D01416EBA89C"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 10 Jul 2019 10:14:37 +0200
In-Reply-To: <46656FBE-06E8-4E65-AF61-4BDE2F206F00@romkey.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, captive-portal@ietf.org, "opsawg@ietf.org" <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>
To: John Romkey <romkey@romkey.com>
References: <B8F9A780D330094D99AF023C5877DABAA49CD8C1@nkgeml513-mbx.china.huawei.com> <CAFpG3gc4ijy+xH7O_9EzpzwcROu3XcTA4xpSAH9P+oyhWQzMyg@mail.gmail.com> <4486.1562683318@localhost> <7534958E-E1A6-470D-B4BB-6B88CD27B54C@cisco.com> <27334.1562697538@localhost> <EE6AC0E8-0596-4B58-AA38-003078BF4B23@cisco.com> <18178.1562719763@localhost> <46656FBE-06E8-4E65-AF61-4BDE2F206F00@romkey.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.166.105, [10.61.166.105]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/IbOuQJUaaT_VRI9mOOfBVhrZ4Tg>
Subject: Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 08:14:45 -0000

Hi John,

> 
> I believe strongly that the only safe thing you can do with a device that’s been in any way compromised is completely isolate it.It shouldn’t be able to send an “unquarantine” signal. You shouldn’t even try to talk to it.
> 

It’s important to tease out the device model here a bit.  If the device is a single processor unit, I can only but agree with you.  However, if there is a TPM/TEE present, things get a bit grayer.  It is possible that even a device with a TEE could have been compromised.  This could have happened through a classic bug in some unprotected code, like a web server.  If code within the TEE is able to detect that it has been messed with, then it is possible it might want to remediate.  It is then up to the process in the TEE to communicate to some sort of remote attestation service to demonstrate that the system is in a nominal state, and up to the RATS server to believe that system or not.

But I must say that this would not my first use of MUD ;-)

Eliot


> Let the firewall which is implementing MUD notify the user about the problem. Let the device’s app or cloud services notify the user that the device is offline. Possibly in a later evolution of MUD the firewall might have a way to notify the device’s cloud service, but I wouldn’t hamstring the initial version of MUD with an attempt to do that.
> 	- john romkey
> 	https;//romkey.com <http://romkey.com/>
>

v2.23.0 | Report a Bug | By Email