Subject: Re: [Mud] [OPSAWG] Fwd: New Version Notification for draft-reddy-opswg-mud-tls-00.txt

From: Qin Wu <[email-masked]>
Date: Tue, 9 Jul 2019 03:00:05 +0000

Interesting work, three questions:

1.       Can the IoT device (D)TLS profile be disclosed to malicious agent or IoT device? If not, how do you prevent these sensitive information leaking?

2.       Do you frequently update DTLS profile disclosed to IoT device to prevent malicious agent from snooping?

3.       How does enterprise firewal use DTLS profile to detect malicious flow or legitimate flow?

-Qin
发件人: OPSAWG [mailto:[email-masked]] 代表 tirumal reddy
发送时间: 2019年7月8日 22:03
收件人: [email-masked]; [email-masked]
主题: [OPSAWG] Fwd: New Version Notification for draft-reddy-opswg-mud-tls-00.txt

This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00 discusses Manufacturer Usage Description (MUD) extension to model (D)TLS profile on IoT devices. This allows a firewall to notice abnormal DTLS or TLS usage, which has been a strong indicator of other software running on the endpoint, typically malware.

Comments, suggestions, and questions are more than welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, 8 Jul 2019 at 19:18
Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
To: Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>, Dan Wing <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-opswg-mud-tls
Revision:       00
Title:          MUD (D)TLS profiles for IoT devices
Document date:  2019-07-08
Group:          Individual Submission
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
Htmlized:       https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to model DTLS
   and TLS usage.  This allows a network element to notice abnormal DTLS
   or TLS usage which has been strong indicator of other software
   running on the endpoint, typically malware.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: tirumal reddy <[email-masked]>
Date: Tue, 9 Jul 2019 15:38:59 +0530

Hi Qin,

Please see inline

On Tue, 9 Jul 2019 at 08:30, Qin Wu <[email-masked]> wrote:

> It is not sensitive information, on-path network devices can inspect or
monitor the TLS handshake without acting as a TLS proxy. In TLS
1.3, ClientHello message is not encrypted and few parameters in the
ServerHello message are still visible (such as the chosen cipher).

> No, Malware frequently uses its own libraries (SSL config) for its
activities, and malware developers will have to develop malicious agents
per IoT device type, manufacturer and model (which will be several
thousands and practically not possible).

> If (D)TLS session from the IoT device violates MUD (D)TLS profile,
firewall detects the flow is malicious and blocks it. As you may know,
Enterprise firewalls inspect TLS handshake and are capable of acting as a
(D)TLS proxy (please see
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-05).

Cheers,
-Tiru

-Qin
>
> *发件人:* OPSAWG [mailto:[email-masked]] *代表 *tirumal reddy
> *发送时间:* 2019年7月8日 22:03
> *收件人:* [email-masked]; [email-masked]
> *主题:* [OPSAWG] Fwd: New Version Notification for
> draft-reddy-opswg-mud-tls-00.txt
>
>
>
> This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
> profile on IoT devices. This allows a firewall to notice abnormal DTLS or
> TLS usage, which has been a strong indicator of other software running on
> the endpoint, typically malware.
>
>
> From: <[email-masked]>
> To: Tirumaleswar Reddy <[email-masked]>, Dan Wing <[email-masked]>
>
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 10:41:58 -0400

Between editing drafts yesterday, I got to thinking about CAPPORT.
I have been working on what to do when an IoT device violates it's MUD
profile.  There are a bunch of issues around this.

Yesterday, it occured to me that when such a device is quarantined
(I really think it should be "quaranteed", but that's not a word)
that the capport controls and APIs should be available to the device to
learn what went on.

This is not new, I think that this as been the approach of most enterprise
NEA systems upon encountering "infection".  This has, I assume, involved
forced HTTP proxies to inform human.  But, if we have APIs, we can inform
device as well.

Is this on anyone's radar?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Jul 2019 16:54:04 +0200

I’m not quite certain how it would work.  Can you show a flow that will work for an IoT device (e.g., headless and no display)?

Eliot

> On 9 Jul 2019, at 16:41, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 14:38:58 -0400

Eliot Lear <[email-masked]> wrote:
    > I’m not quite certain how it would work.  Can you show a flow that will
    > work for an IoT device (e.g., headless and no display)?

Device gets quarantined, and the MUD-controller moves it into an isolated
"VLAN".  I put air/scare quotes around VLAN, because it's a "MAC-address
VLAN", not an 802.1Q thing.  It's really just a layer-2 ACL.

{We have no way to force the mishaving device into tagging it's packets, nor
can we force it onto some other ESSID. We can't do a "port-based" VLAN,
because wifi has no ports, and we don't really know how many unmanaged
switches might be on the port anyway.
One might map this onto a IEEE 802.1Q VLAN across a backbone}

Instead of just dropping all traffic for a device in this category,
all traffic (other than excepted traffic if you implement
https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/)
would go into a captive portal system.

Such a system would, according to
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
receive a message when it initiates connections which are not allowed.
(While the capport WG contemplated an ICMP unreachable message with a
URI in it at one point, that is not the current design)

Actually, I have no idea from reviewing the documentation what the
appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?

Once the IoT device gets such a message, it can use the API
described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
to retrieve a JSON object telling it that it is captive. At which point, it
can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
timer goes off.  (%)

This requires that the IoT device get the captive portal API end point, which
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver
via DHCPv4/v6 or RA.

    >> Between editing drafts yesterday, I got to thinking about CAPPORT.  I
    >> have been working on what to do when an IoT device violates it's MUD
    >> Yesterday, it occured to me that when such a device is quarantined (I
    >> really think it should be "quaranteed", but that's not a word) that
    >> the capport controls and APIs should be available to the device to
    >> learn what went on.
    >>
    >> This is not new, I think that this as been the approach of most
    >> enterprise NEA systems upon encountering "infection".  This has, I
    >> assume, involved forced HTTP proxies to inform human.  But, if we have
    >> APIs, we can inform device as well.
    >>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Jul 2019 20:52:25 +0200

It’s the following part that I’m thinking about:

> On 9 Jul 2019, at 20:38, Michael Richardson <[email-masked]> wrote:
> 

You are suggesting that a device self-remediate.  Some devices may be able to eventually do that, but I have my doubts.  Were I a hacker, I would have the device pretend to do just that.  And so this ties somewhat to RATS.  I think a MUD extension might be able to help in as much as one could imagine a “remediation” recommendation.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 9 Jul 2019 16:13:06 -0400

The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
Assumes that the "quarantined device" can access a subset of the ACE's
allowed to the "unquarantined" device.
However, I can think of a scenario where this does not have to be the case.
I'd propose to generalize this.

i.e. There are two sets of ACL's - one for normal operation and one for
quarantined access. (i.e. quarantine access is not necessarily a subset of
regular access).

Use case:

Under normal circumstances, the device does not need SSH access (port 22 is
not open). However, if the device is misbehaving some external agent (or
human maybe) logs in and investigates the issue.  The fix could involve
copying new firmware.

Does this make sense?

Another thing that is missing currently is how to "clear" the quarantine
state at the enforcement point. This would need an API defintion of we want
to make that portable.

Regards,

Ranga

On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson <[email-masked]>
wrote:

> I
> (I
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 9 Jul 2019 16:16:39 -0400

> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/

Wrong reference, I meant

https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/

(sorry for extra email load).

> However, I can think of a scenario where this does not have to be the
> case. I'd propose to generalize this.
>
> Under normal circumstances, the device does not need SSH access (port 22
> is not open). However, if the device is misbehaving some external agent (or
>>     >> On 9 Jul 2019, at 16:41, Michael Richardson <[email-masked]
>> >
>>     >> wrote:
>>     >>
>>     >> Signed PGP part
>>     >>

-- 
M. Ranganathan

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Tue, 9 Jul 2019 20:33:26 +0000

Most of the devices I think of as actual IoT devices have no direct UI/shell.  Your only interaction with them after initial “install/configure” is through their cloud web service interface.  Having said that I think your model is fine.

I would suggest detecting device reboot would be one signal to clear quarantine state.  Since MUD “misbehavior” is mostly instantaneously detectable (1 packet), I am not that concerned that the device might reboot for others reasons and still be infected.

One might keep a counter and a time stamp of quarantine clears and if you a device had N MUD violations after quarantine clears in X time, lock it down in quarantine or completely take it off line.

dougm

--
DougM at NIST

From: "IETF-MUD LIST:" <[email-masked]> on behalf of Mudumbai Ranganathan <[email-masked]>
Date: Tuesday, July 9, 2019 at 4:13 PM
To: Michael Richardson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal

The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/<https://datatracker.ietf..org/doc/draft-ietf-capport-api/>
Assumes that the "quarantined device" can access a subset of the ACE's allowed to the "unquarantined" device.
However, I can think of a scenario where this does not have to be the case. I'd propose to generalize this.

i.e. There are two sets of ACL's - one for normal operation and one for quarantined access. (i.e. quarantine access is not necessarily a subset of regular access).

Use case:

Under normal circumstances, the device does not need SSH access (port 22 is not open). However, if the device is misbehaving some external agent (or human maybe) logs in and investigates the issue.  The fix could involve copying new firmware.

Does this make sense?

Another thing that is missing currently is how to "clear" the quarantine state at the enforcement point. This would need an API defintion of we want to make that portable.

Regards,

Ranga

On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Instead of just dropping all traffic for a device in this category,
all traffic (other than excepted traffic if you implement
https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-richardson-shg-mud-quarantined-access%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363419649&sdata=t5GQKZst%2BCezofO4a7vGekkILbIkf%2FSWmG5vfcX9Ao4%3D&reserved=0>)
would go into a captive portal system.

https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363429646&sdata=%2FYsk7daSV5qv%2B%2B5gS7YDyH%2BhlwDZhkdbrYij9RQn8GA%3D&reserved=0>

Once the IoT device gets such a message, it can use the API
described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-api%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363429646&sdata=Na%2FWWVybCuYWxOYILb%2BOlL99q1bZNz0qopbhVWggqI4%3D&reserved=0>
to retrieve a JSON object telling it that it is captive. At which point, it
can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
timer goes off.  (%)

This requires that the IoT device get the captive portal API end point, which
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-rfc7710bis%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363439631&sdata=Nafuv7GJEwFuQeA5GxByWPU8aJGd5Dxunv%2FbOyqsFjA%3D&reserved=0> can deliver
via DHCPv4/v6 or RA.

    >> On 9 Jul 2019, at 16:41, Michael Richardson <mcr+ietf@sandelman..ca<mailto:[email-masked]>>
    >> wrote:
    >>
    >> Signed PGP part
    >>
    >> assume, involved forced HTTP proxies to inform human..  But, if we have
    >> Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--
Mud mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mud<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmud&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363439631&sdata=jfX9DMHG9ccfEW92JCQWhPO1FAXKFGf2o4L1M3lTlJY%3D&reserved=0>

--
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 20:49:23 -0400

> It’s the following part that I’m thinking about:

...

    > You are suggesting that a device self-remediate.  Some devices may be
    > able to eventually do that, but I have my doubts.  Were I a hacker, I
    > would have the device pretend to do just that.  And so this ties
    > somewhat to RATS.  I think a MUD extension might be able to help in as
    > much as one could imagine a “remediation” recommendation.

Yes, so a full attack on the IoT device would do what you describe.
A partial attack might miss messing this.  A reboot might clear out the
malware, or might mitigate it enough (such as going to boot firmware) that
would permit new firmware to be loaded.

Yes, getting completely out of the quarantine would require either
attestation or human intervention.  But, if the device now has good firmware,
it would be able to send the "please unquarantine me" signal.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 20:53:00 -0400

Juergen Schoenwaelder <[email-masked]> wrote:
    > would an ICMP "administratively prohibited" not be a sufficient
    > signal? Sure, things can be made much more complex, but I doubt that
    > devices will try to actively investigate why they can't communicate

Probably good enough.  Some wanted a more specific signal.

It's intended to just be a signal to go ask the captive portal API
if the device is captive.

    > (and implement additional protocols for this) if all they can do at
    > the end is to change the color of an led or simply shut-off (i.e.,
    > stop assuming its a temporary network issue and reduce/stop probing
    > effort).

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 21:05:01 -0400

Montgomery, Douglas (Fed) <[email-masked]> wrote:
    > Most of the devices I think of as actual IoT devices have no direct
    > UI/shell.  Your only interaction with them after initial
    > “install/configure” is through their cloud web service interface.

That's true for many devices, but not all.
Even light bulbs have output interfaces :-)

    > Having said that I think your model is fine.

Good.

    > I would suggest detecting device reboot would be one signal to clear
    > quarantine state.  Since MUD “misbehavior” is mostly instantaneously
    > detectable (1 packet), I am not that concerned that the device might
    > reboot for others reasons and still be infected.

Device reboot probably needs an attestation to be believed.

    > One might keep a counter and a time stamp of quarantine clears and if
    > you a device had N MUD violations after quarantine clears in X time,
    > lock it down in quarantine or completely take it off line.

Reasonable, but in the space of quality of implementation, I think.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 21:15:56 -0400

{my appologies for still getting captive-portal vs captive-portals@ wrong}

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

That's a reasonable view.
The question is: what next?
                   draft-richardson-shg-un-quarantine-00
tries to discuss this.

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

I fully expect any notifications out should be done by the firewall.
There are two issues I'm trying to address:
  1) there will be false positives from use of MUD.  Manufacturers will
     screw up, DNS mappings will be updated out of sync with firmware, etc.
     If it is too painful to diagnose and fix, then MUD will get disabled by
     operators (ISPs, who will get the call), or by end users.

  2) not every user of a device will get the notifications.
     So devices with displays (think: thermostats, refridgerators, SIP phones,
     TV sets, etc.) whether they have real malware on them, or false
     positives should be able to indicate that they are offline.
     This matters a lot if you are trying to dial 911 on a broken phone,
     and you aren't the person with the app that gets the notifications
     from the firewall.

Putting them behind the captive-portal API when quarantined lets them get
exactly the kind of information they want.  It also helps them when they
turned on where there really is a captive-portal.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Jul 2019 10:14:37 +0200

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jul 2019 21:46:14 +0200

Michael,

/js

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: John Romkey <[email-masked]>
Date: Tue, 9 Jul 2019 17:58:27 -0700

> On Jul 9, 2019, at 5:49 PM, Michael Richardson <[email-masked]> wrote:
> 
>