Subject: [Ace] Personal Health Monitoring

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Dec 2014 13:57:51 +0100

I read through the personal health monitoring and have a few remarks

I would re-write the first paragraph to

"
he use of wearable technology for use with fitness and health monitoring
is growing strongly, as a multitude of novel devices are made available
to end customers.

The need for open industry standards to ensure interoperability between
products has lead to initiatives such as Continua Alliance
(continuaalliance.org) and Personal Connected Health Alliance
(pchalliance.org).

Personal fitness and health devices are typically battery powered, and
located physically on the users body to monitor heart rate, temperature,
blood pressure, movement, etc. They are typically connected to the
Internet through the use of smart phones. The uploaded data can be used
for Through this connection they report the monitored data is made
available to the user for measuring training success, monitor health
status, to alert emergency services personnel in case of problems, and
to motivate the user to improve their lifestyle. Data sharing to
friends, relatives, personal trainers and doctors is common.
"

"
   The HeartGuard also broadcasts emergency
   information in the neighborhood to notify doctors or people with
   certain skills who have been enrolled in an emergency program, e.g.
   people who got training in heart and lung rescue.  For doctors,
   medical information or diagnosis can be provided with the
   notification to improve immediate treatment.
"

How is this going to work? I guess it is more realistic to get help when
you call 1-1-2 or 9-1-1 than broadcasting beacons on Bluetooth or WiFi
for help (since others in close proximity need to have an application
listening for it). It is more likely that they will see you on the ground.

"
   The device includes some smart logic, with which it identifies its
   owner John and allows him to configure the device's settings,
   including access control.
   This prevents situation where someone else wearing that device can
   act as the owner and mess up the access control and security
   settings.
"

I guess by device you do not mean the heart rate monitor itself but
rather some other device. Typically, heart rate monitors are quite small
(since you often carry them around your chest). It would make sense if
the smart device is something like a smart phone since that also has a
display.

"
   However John is a rather private person, and is worried that Jill
   might use HeartGuard to monitor his location while there is no
   emergency.  Furthermore he doesn't want his health insurance to get
   access to the HeartGuard data, or even to the fact that he is wearing
   a HeartGuard, since they might refuse to renew his insurance if they
   decided he was too big a risk for them.
"

You should write "John is a privacy conscious persons and is worried
that Jill ...."

I also notice again the out-of-scope requirements for secure by default,
easy to use, etc.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Dec 2014 15:26:26 +0100

I wanted to add some thoughts about the use of health information for
emergency services situations.

Here is how this works today with a solution called Smart911 from Rave
Mobile Security (as it was explained to me by Mark Fletcher). To my
knowledge Smart911 has a pretty reasonable deployment in the US.

I call 911.

The PSAP takes my calling party number to the Smart 911 system and
queries the database.

Smart911 responds with my personal safety profile that I have created.
(Obviously, the PSAP needs to have software running to do all this.)

I can store anything there from floor plans to meds, emergency contacts,
etc. (This is the data described in the IETF ECRIT additional data work:
http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-25)

Today, these systems do not provide ways to say "I am OK with sharing
the data with the emergency services system but don't share it with Dr. No."

The reason is not so much about the complexity of the authorization
policies (or the lack of interest to configure policies in such a way)
but rather tied to the way how the emergency services system works with
the PSAP call takers and the largely independent first responders and
the rest of the healthcare infrastructure. It is all or nothing. That
makes also a lot of sense to give the emergency services system some
flexibility regarding my emergency response.

Hence, I believe this requirement is really sci-fi:

"
   o  U3.3 A device owner wants to block access to specific persons in
      an otherwise allowed group (e.g. doctors in an emergency), if he
      mistrusts them.
"

I would suggest to delete it or mark it as something nice to have in the
future when many other preconditions are fulfilled.

Ciao
Hannes

On 12/06/2014 01:57 PM, Hannes Tschofenig wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 08 Dec 2014 10:16:23 +0100

> listening for it). It is more likely that they will see you on the ground.

When I wrote that I was thinking that the device would have an Internet 
connection through some intermediate device (e.g. the smartphone of the 
individual carrying the device).

Are you thinking of a device that would have a SIM card and thus be 
connected to the mobile network?

> the smart device is something like a smart phone since that also has a

That's actually a very interesting question: Do we consider the heart 
rate monitor a stand-alone device, or does it need an additional (more 
powerful) device to function?

If we consider the second case, how is the connection between the 
monitor and the more powerful device secured?

I tried to get some feedback from the ECRIT WG at IETF 90 in order to 
improve this use case, but I didn't get any response.

> I also notice again the out-of-scope requirements for secure by default,

Ok

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 08 Dec 2014 10:21:04 +0100

> future when many other preconditions are fulfilled.

It was actually a requirement in a Swedish patient-record management 
system I once worked on. However I think it was never used in practice 
and certainly not on constrained devices.

I'll delete this in the next update.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 09 Dec 2014 12:20:26 +0100

Hi Hannes,

On 12/06/2014 01:57 PM, Hannes Tschofenig wrote:

> " The device includes some smart logic, with which it identifies
> its owner John and allows him to configure the device's settings, 
> including access control. This prevents situation where someone
> else wearing that device can act as the owner and mess up the
> access control and security settings. "
> 
> I guess by device you do not mean the heart rate monitor itself
> but rather some other device. Typically, heart rate monitors are
> quite small (since you often carry them around your chest). It
> would make sense if the smart device is something like a smart
> phone since that also has a display.

I think the heart rate monitor itself should be able to enforce
authorization policies of the owner. Otherwise the device would not be
able to decide if someone is supposed to access data on the device,
e.g. health data. Since privacy is a concern for medical data, only
authorized users should be able to access it.

> 
> " However John is a rather private person, and is worried that
> Jill might use HeartGuard to monitor his location while there is
> no emergency.  Furthermore he doesn't want his health insurance to
> get access to the HeartGuard data, or even to the fact that he is
> wearing a HeartGuard, since they might refuse to renew his
> insurance if they decided he was too big a risk for them. "
> 
> You should write "John is a privacy conscious persons and is
> worried that Jill ...."
> 
> 
> I also notice again the out-of-scope requirements for secure by
> default, easy to use, etc.

As I stated before, I don't think that usability is out of scope.
Neither is privacy.

Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 14:32:49 +0100

Hi Steffi,

> authorized users should be able to access it.

It would be worthwhile to point this out in the document since this is
certainly quite different to the way how heart rate sensors work today.

Most of these types of appliances are using ANT/ANT+ and more recently
Bluetooth Smart to talk to some other device. The wireless connection is
basically a replacement for a pure wire since you could compare the
heart rate sensor with a computer mouse. The mouse gathers data but the
processing really happens at the device it is attached to. Since ANT and
Bluetooth Smart are short range radio technologies you need to have some
other device nearby.

The standards for these heart rate monitors are in fact quite
restrictive in terms of functionality. For example, the Bluetooth Smart
heart rate profile only allows a single instance of a Heart Rate Service
and multiple bonds are outside the scope of the spec.

So, the question is really whether there is any value to deviate from
the current use of the technology? If there is, then there might be
reasons for doing so. We should state them.

> As I stated before, I don't think that usability is out of scope.

The question for the standardization work is whether it will have an
impact on protocol interoperability. Usability as well as default
policies for security and privacy are important but they are not
something we would define in the specification.

Ciao
Hannes

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 12 Dec 2014 14:29:21 +0100

Hi Hannes,

On 12/11/2014 02:32 PM, Hannes Tschofenig wrote:
>>> " The device includes some smart logic, with which it
>>> identifies its owner John and allows him to configure the
>>> device's settings, including access control. This prevents
>>> situation where someone else wearing that device can act as the
>>> owner and mess up the access control and security settings. "
>>> 
>>> I guess by device you do not mean the heart rate monitor
>>> itself but rather some other device. Typically, heart rate
>>> monitors are quite small (since you often carry them around
>>> your chest). It would make sense if the smart device is
>>> something like a smart phone since that also has a display.
>> 
>> authorization policies of the owner. Otherwise the device would
>> not be able to decide if someone is supposed to access data on
>> the device, e.g. health data. Since privacy is a concern for
>> medical data, only authorized users should be able to access it.
> 
> It would be worthwhile to point this out in the document since this
> is certainly quite different to the way how heart rate sensors work
> today.

One problem of many medical solutions used today is that they lack
security. If today's solutions do not protect the privacy of their
users and unauthorized users are able to access private data I think
we should try to find better solutions for these problems.

I agree that we should point this out in the document.

> 
> Most of these types of appliances are using ANT/ANT+ and more
> recently Bluetooth Smart to talk to some other device. The wireless
> connection is basically a replacement for a pure wire since you
> could compare the heart rate sensor with a computer mouse. The
> mouse gathers data but the processing really happens at the device
> it is attached to. Since ANT and Bluetooth Smart are short range
> radio technologies you need to have some other device nearby.
> 
> restrictive in terms of functionality. For example, the Bluetooth
> Smart heart rate profile only allows a single instance of a Heart
> Rate Service and multiple bonds are outside the scope of the spec.
> 
> So, the question is really whether there is any value to deviate
> from the current use of the technology? If there is, then there
> might be reasons for doing so. We should state them.

I don't see how that contradicts that the heart rate monitor must be
able to enforce authorization policies and protect the privacy of the
user.

Even if the heart rate monitor is coupled with a stronger device that
helps with the authorization decisions, the heart rate monitor should
still be able to conduct basic security tasks such as enforcing the
policies of the owners. draft-gerdes-ace-actors [1] states which tasks
a constrained device should at least be able to conduct. Without any
security mechanism on the heart rate monitor, everyone could read the
measured data. An inappropriate security mechanism might lead to
breaching security objectives that are important for the use case:
unauthorized entities might be able to access (integrity and
confidentiality breaches) or authorized entities might not be able to
access (availability breaches).

I would not go too deep into solution specific details at this point.
I think it is not the purpose of the use cases document to define use
cases that fit certain solutions but to point out the relevant
authorization problems since this is the first step to reach one goal
of ACE: finding a solution for the exisiting authorization problems.
If we find out that there already are solutions for some of the
problems and we only need to combine them in a useful way, that would
be a good result. If we only see parts of the picture because we are
leaving out main problems as they don't seem to be that interesting at
this point, we might not be able to find the best solution.

>>> Jill might use HeartGuard to monitor his location while there
>>> is no emergency.  Furthermore he doesn't want his health
>>> insurance to get access to the HeartGuard data, or even to the
>>> fact that he is wearing a HeartGuard, since they might refuse
>>> to renew his insurance if they decided he was too big a risk
>>> for them. "
>>> 
>>> I also notice again the out-of-scope requirements for secure
>>> by default, easy to use, etc.
>> 
>> As I stated before, I don't think that usability is out of
>> scope. Neither is privacy.
> 
> The question for the standardization work is whether it will have
> an impact on protocol interoperability. Usability as well as
> default policies for security and privacy are important but they
> are not something we would define in the specification.

Usability is important to consider for a specification that is
intended to provide security. I think we agree on that. There are more
ways to ensure usability than to decide how the user interface has to
look like. So I think it has an impact on the protocol design and
interoperability.

I also think it is important to understand why authorization is needed
in the various use cases. For some use cases, privacy is important. I
hope that the need for privacy will have an impact on the solution
design. Since it is especially important for some use cases, it is
useful to mention privacy problems there.

I agree that the secure default settings problem (U3.5) is rather a
configuration problem. Since it is true for all use cases we can
remove it from the problems section. It is already mentioned in 3.3 of
the security considerations section.

Steffi

[1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Dec 2014 10:35:09 +0100

Hi Steffi,

thanks for the feedback.

A few remarks below.

> I agree that we should point this out in the document.
Thanks.

> access (availability breaches).

I agree that there has to be some security protection for the data
stored at the heart rate monitor and also channel security for the
transmission of the heart rate readings.

If there is a one-to-one relationship between the heart rate monitor and
the parent device (such as a smart phone or a watch) this security
protection is fairly easy to accomplish. The authorization policy at the
heart rate monitor is as simple as: "Only the device I have paired with
is allowed to access the data."

> this point, we might not be able to find the best solution.

The good thing about use cases is that they are specific. Whether we
want to make the use cases align with existing technologies (such as
radio technologies) is a decision we make, as document authors and also
within the group. We could also state in the document that some of the
use cases describe approaches that are in use today while others are
more forward-looking because we are not happy with the way how things
are today.

That's perfectly fine with me.

> the security considerations section.

It would be great if we could figure out how the usability aspect
(security & privacy) impacts our work. RFC 6973 might give us some
hints. Section 7.2, for example, talks about user participation and I
believe we capture the first two points (namely user control and control
over sharing with individual recipients) quite well in
http://tools.ietf.org/html/draft-ietf-ace-usecases-00#section-2.3.2.

We don't talk about preference expressions or the sharing with
intermediaries. Maybe those two aspects are not of interest or not
applicable to this use case.

For the following two items, however, we could provide a bit more context:

   o  U3.5 Devices are often used with default access control settings.

[Hannes: I would say that we are talking about the heart rate monitor
initially configured so that it does not share any data with other
sensors (such as a GPS sensor), with intermediaries (like a smart phone,
watch, or a gateway), with a cloud service (although the cloud service
is not explicitly found in the description), or with other
applications/web sites/and users.]

   o  U3.6 Device users are often not trained in computer use and
      especially computer security.

[Hannes: Here I had difficulties providing an additional description of
what this would mean for the use case. Given the previous requirement
the user obviously has to configure the device to share data with
various other parties since otherwise nothing works. He does not need to
understand how the actual protocol mechanisms work or what crypto it
uses but it could be good for the user to know that the device complies
to specific standards and that there may even have been
self-certification/third party certification activities. The latter
aspect is outside the scope of our work and even the IETF and the best
way to deal with the former is to re-use existing patterns users are
already familiar with. In any case I fear that those would also be
outside the scope of our work. We could, however, provide a bit more
background text to explain what we mean and note that this work has to
happen somewhere else. ]

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Dec 2014 18:07:25 +0100

On 16 Dec 2014, at 10:35, Hannes Tschofenig <[email-masked]> wrote:
> 
> The authorization policy at the

That’s great for “lifestyle” bluetooth smart devices you use with your smartphone and, say, HealthKit.

I think 2.3.1 describes a more interesting medical use case.

Grüße, Carsten