Subject: [hrpc] Authorization for IoT devices

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2021 22:02:37 -0400

HRPC folks,

Today, I made a presentation at IOTOPS about
       https://datatracker.ietf.org/doc/draft-richardson-iotops-iot-iot/
I will send a youtube link as soon as it is published.

The short is that I see a need to standardize the encoding of authorization
control lists in IoT devices.   It should be possible to determine who can
open one's front door, (or furnace or stove or security cameras...), and
also who can change the list.

I think that it should be possible to have a third party (person, device,
application) review the authorization list to see that, for instance, an
ex-spouse does not have access.  Or to allow a less technical person to
easily effect that new policy.

The access list might include a variety of other entities: banks with
mortgages, sherrif, landlord, building manager.  Some of these might be
proclaimed by local law, convention, or contract.   My goal isn't to say
whether these are good or bad things, but rather to be able to clearly
document them.   I don't know if your furnace manufacturer should have remote
access, but if they do, it should be explicit rather than implicitely
built-in to firmware.

I know that HRPC meets Tuesday, but I didn't ask for time because my week is
already full.  I'm asking that the RG might review the document, look at the
use cases, and ideally:
  1) suggest new ones
  2) tell me why some of mine are silly
  3) connect me with people who might be thinking about regulation in this area.

(The NYC key 2642/1620 situation begs for an auditable digital solution)

While I wrote the document about front door locks, one should think that it
applies to pretty much any major IoT device in the home.   While some systems
have a controller or commissioner or "home base" that collects the keys to
all other devices, in that case, who has the keys to his key holder?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Jul 2021 10:00:32 +0000

Have you tried to use ACE-OAuth, Michael?

The work in the ACE group had the goal to develop an authorization solution for IoT devices.

-----Original Message-----
From: Iotops <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, July 27, 2021 4:03 AM
To: [email-masked]; [email-masked]
Subject: [Iotops] Authorization for IoT devices

HRPC folks,

The short is that I see a need to standardize the encoding of authorization
control lists in IoT devices.   It should be possible to determine who can
open one's front door, (or furnace or stove or security cameras...), and also who can change the list.

I think that it should be possible to have a third party (person, device,
application) review the authorization list to see that, for instance, an ex-spouse does not have access.  Or to allow a less technical person to easily effect that new policy.

The access list might include a variety of other entities: banks with mortgages, sherrif, landlord, building manager.  Some of these might be
proclaimed by local law, convention, or contract.   My goal isn't to say
whether these are good or bad things, but rather to be able to clearly
document them.   I don't know if your furnace manufacturer should have remote
access, but if they do, it should be explicit rather than implicitely built-in to firmware.

I know that HRPC meets Tuesday, but I didn't ask for time because my week is already full.  I'm asking that the RG might review the document, look at the use cases, and ideally:
  1) suggest new ones
  2) tell me why some of mine are silly
  3) connect me with people who might be thinking about regulation in this area.

While I wrote the document about front door locks, one should think that it
applies to pretty much any major IoT device in the home.   While some systems
have a controller or commissioner or "home base" that collects the keys to all other devices, in that case, who has the keys to his key holder?

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Jul 2021 21:52:16 -0400

> Have you tried to use ACE-OAuth, Michael?

My understanding is that it requires a AS to evaluate the request and the
generate a ticket/token for the RS.

1) many people perceive the AS as being the cloud component and they don't
   want a cloud part.

2) but in any case, it's the form of the rules which the AS evaluates to
   make the authorization decision that I care about.  AFAIK, neither
   OAUTH2 or ACE-OAUTH standardizes that (or intends to).

    > solution for IoT devices.

If I'm wrong please correct me.
How would ACE-OAuth identify the local Sheriff?

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Jul 2021 12:40:24 +0000

Hi Michael,

Remarks below:

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Wednesday, July 28, 2021 3:52 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iotops] Authorization for IoT devices

    > Have you tried to use ACE-OAuth, Michael?

My understanding is that it requires a AS to evaluate the request and the generate a ticket/token for the RS.

[Hannes] You have to get the permissions from somewhere since you can hardly create your own permissions...

[Hannes] The AS may be in the cloud but it may be anywhere else -- whatever is most appropriate in a given deployment.

[Hannes] In deployments today the rules are not standardized because they are configured by the user/admin into the AS. What gets pushed around are permissions, which are defined for specific application domains. These permissions are called "scopes" in the OAuth language. Some of those scopes have been standardized.

There has also been an attempt to standardize more generic ACLs,
see draft-ietf-ace-aif.

[Hannes] The purpose of an authorization framework is not to identify a specific person. That's the role of an identity management framework. What ACE/OAuth would be able to do is to give the local sheriff a token so that they can access specific resources. What resources they can access depends on the configured authorization policies.

If you also want to add the identity management piece to ACE/OAuth (which people have obviously done), then you can add OpenID Connect and, for example, FIDO to the mix.

I hope this now makes more sense.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Jul 2021 14:25:39 -0400

Hannes Tschofenig <[email-masked]> wrote:
    mcr> 2) but in any case, it's the form of the rules which the AS evaluates to
    mcr> make the authorization decision that I care about.  AFAIK, neither
    mcr> OAUTH2 or ACE-OAUTH standardizes that (or intends to).

    Hannes> In deployments today the rules are not standardized because they
    Hannes> are configured by the user/admin into the AS. What gets pushed
    Hannes> around are permissions, which are defined for specific
    Hannes> application domains. These permissions are called "scopes" in the
    Hannes> OAuth language. Some of those scopes have been standardized.

Thank you for confirming my understanding.
I'm looking for a standard for the rules.

Why? because auditing, because humans need to understand them, because
configuring the rules needs to be something non-experts can do.

    > There has also been an attempt to standardize more generic ACLs,

Not even close, I think.

    mcr> If I'm wrong please correct me.
    mcr> How would ACE-OAuth identify the local Sheriff?

    Hannes> The purpose of an authorization framework is not to identify a
    Hannes> specific person. That's the role of an identity management
    Hannes> framework.

It's not a specific person, it's a specific role in an particular geography.
That's why this problem is non-trivial.

    > If you also want to add the identity management piece to ACE/OAuth
    > (which people have obviously done), then you can add OpenID Connect
    > and, for example, FIDO to the mix.

If we can really do this with those specifications, I'd be interested in
knowing how, or seeing an example of a system which has done that.

I'm actually convinced that we don't need a lot of new work ("new
ingredients") to make things go, but I think that we need a clear
architecture on combining existing work ("better recipes")

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Jul 2021 18:44:50 +0000

Hi Michael,

~snip!
    Hannes> OAuth: Some of those scopes have been standardized.

Michael: Thank you for confirming my understanding.
Michael: I'm looking for a standard for the rules.
Michael: Why? because auditing, because humans need to understand them, because configuring the rules needs to be something non-experts can do.

Here are some examples on what has been standardized:

Section 5.4 of the OpenID Connect Core specification defines a few scope values related to identity management:
https://openid.net/specs/openid-connect-core-1_0.html

The healthcare specification in the OIDF defines scopes in their "Health Relationship Trust (HEART)" specification:
https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html

More specs of the OIDF from other application domains can be found here:
https://openid.net/developers/specs/

In the OAuth working group we also have some work on scopes as part of the work on rich authorization requests. See Appendix A for examples:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05

    > There has also been an attempt to standardize more generic ACLs,

Michael: Not even close, I think.

This is work in progress; so you can suggest changes.
You could push it all the way to turn it into XACML:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Michael: It's not a specific person, it's a specific role in an particular geography.
Michael: That's why this problem is non-trivial.

This is why you will have to work out standards for certain application domains since otherwise this will get so complex that nobody is going to use it.

    > and, for example, FIDO to the mix.

Michael: If we can really do this with those specifications, I'd be interested in knowing how, or seeing an example of a system which has done that.

FIDO has a whitepaper that talks about the interaction between FIDO and identity management technology, see
https://media.fidoalliance.org/wp-content/uploads/Enterprise_Adoption_Best_Practices_Federation_FIDO_Alliance.pdf
https://fidoalliance.org/fido-and-federation-protocols-tech-note/

FWIW we, as part of Pelion, even have a product doing this for IoT use cases. I blogged about it a while ago:
https://community.arm.com/developer/research/b/articles/posts/mbed-secure-device-access-enhancing-iot-device-management-with-user-authentication-and-fine-grained-access-control
Here is some more info about the product called "Secure Device Access":
https://developer.pelion.com/docs/device-management/v4.1/sda/index.html

Michael: I'm actually convinced that we don't need a lot of new work ("new ingredients") to make things go, but I think that we need a clear architecture on combining existing work ("better recipes")

That would obviously be good.

Ciao
Hannes