Subject: Re: [Ace] Use Case draft

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Aug 2014 01:35:39 -0400

{at the risk of repeating myself and boring everyone}

Carsten Bormann <[email-masked]> wrote:
    >>> 2) Secret provisioning is another important problem to
    >>> solve. Scenario is : I bring home my new thermostat and want to
    >>> associate it with my account, how is it paired?

    > ACE needs to enable this.  (And it may want to work without requiring
    > the concept of “account”.)  The initial method of pairing or whatever
    > is out of scope (being able to keep it here is one of the points of the
    > differentiation between AM and AS).

My take is that the pairing of the thermostat with the AM is out of scope.
Once paired, the process by which the AM helps the thermostat talk to the
furnace or AC or your Mike's Wife's Phone (Henceforth: MWP) is in scope.

    >>> Later when I sell my house, how to I transfer ownership of the
    >>> thermostat? The most common pattern seems to
    >> 
    >> Out of scope for ACE at this time.

    > Ownership transfer is an important authorization use case.  (The more
    > interesting question, how do you forcibly gain ownership for the
    > contents of a foreclosed home, is way out of scope, though.)

On the day your house transfer closes, you arrange to disclose your keys
(yes, your private house keys) to the new owner, probably via your lawyer.
Probably these are the keys used by the AM/AS to talk to the constrained
devices, not the ones on your phone.   The new owner uses either the existing
AM/AS (after a factory default), or a replacement AM/AS to rekey the entire
network, same as you would change the tumblers on your house.

As for foreclosure, the banks will presumably want things escrowed to them,
just as they insist that I have life insurance as a condition of my
mortgage. (and will happily sell that to me if I'm stupid)

    >> See UCAN BOF.

    > I don’t think UCAN discusses ownership transfer.

If there are certificates from manufacturer to owner as part of the network
ownership claim that UCAN envisions, then ownership transfer amounts to
adding another layer in a certificate chain.  There are various ways to do
this, with different properties.
But, that relationship is about bootstrapping the C/AM pairing, and is out of
scope for ACE.

    >>> 2) If somebody sides a malicious "puck" device under my door, what
    >>> keeps it from joining the other things in the home and attacking the
    >>> house.

    > If the ACE protocols are not secure against this I have no idea
    > whatsoever what we are trying to do.  (It’s not exactly a “use case” in
    > the classical sense; maybe we should be explicit about misuse cases and
    > threats in general.)

There are three threats for the puck.
      1) the puck successfully joins the network and tries to do things to
         existing devices.  ACE is all about securing this.
      2) the puck tries to join the network; but the network refuses. Not in
         scope for ACE.
      3) the puck presents itself as the network to other (new?) devices, and
         tries to get them to join it's network, possibly MiTM them.
         Also out of scope.

    >>> 3) If I have guests and I want to give control of some parts of my
    >>> home, how is that done? Use of proximity is one interesting idea I've
    >>> heard here, if you are in my house you can turn lights on and off.

    > Again, ACE needs to enable this.  The method of proximity/in-perimeter
    > detection is out of scope.

If there is a proximity sensor, then it might act as a sort of RS, AS or AM,
which may provide an ACE format ticket that indicates the C is proximate,
and presenting this ticket to another RS (the light), might be enough to
control it.  The protocol by which the proximity sensor pairs with you
(determines your proximity) is probably out of scope,  the result of the
pairing should be in scope.

-- 
Michael Richardson
-on the road-

---

From: Rene Struik <[email-masked]>
Date: Fri, 01 Aug 2014 10:31:09 -0400

On 8/1/2014 1:35 AM, Michael Richardson wrote:
>      > the concept of "account".)  The initial method of pairing or whatever
RS>>
Addressing authorization for the entire trust lifecycle, rather than for 
the trust lifecycle minus initial provisioning, seems to be easier. 
Conceptually, it is also a somewhat artificial divide, but also 
practically it may result in local optimizations that are not 
necessarily globally close to optimal (and worst case may not work).
<<RS
> network, same as you would change the tumblers on your house.
RS>>
If private keys are never exposed outside a device, ownership transfer 
may only involve a change to *public* configuration tables (what I would 
term "role to device mappings"), at least if one uses public key based 
techniques. These could simply be propagated over the network. Not sure 
why one would need to introduce another employment vehicle for lawyers, 
notaries, and legal departments and add cost where almost zero-cost 
seems possible.
<<RS
> mortgage. (and will happily sell that to me if I'm stupid)
RS>>
If one defines a master controller, who has the authority to 
re-configure settings, in case of unwilling former home owners, this 
could be addressed. This falls into the same category as "click here if 
you forgot your password", but with some more policies (so as to provide 
checks and balances) around this.
<<RS
>      >> See UCAN BOF.
>
>      > I don't think UCAN discusses ownership transfer.
>
> adding another layer in a certificate chain.
RS>>
Not sure I understand this. This seems to suggest that certificate 
chains would encode the entire history of device ownership. In my mind, 
one should be able to logically transition ownership roles, whereby one 
can completely cut ties with the past (use case: installer is done with 
configuring network of lights in hotel lobby and should be "forgotten" 
entirely once the job is done and also logically be cut off moving forward).
<<RS
> There are various ways to do
>      > whatsoever what we are trying to do.  (It's not exactly a "use case" in
RS>>
Still, this is simply an authorization decision by a recipient device 
somewhere in the network, not that different from other authorization 
decisions.
<<RS
>      > detection is out of scope.
RS>>
Here, authorization is based on contextual information, similar to time 
of day of message receipt (here: observed purported location).
<<RS

If there is a proximity sensor, then it might act as a sort of RS, AS or 
AM, which may provide an ACE format ticket that indicates the C is 
proximate, and presenting this ticket to another RS (the light), might 
be enough to control it. The protocol by which the proximity sensor 
pairs with you (determines your proximity) is probably out of scope, the 
result of the pairing should be in scope.
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 1 Aug 2014 21:35:00 +0000

I'm not sure why you are saying these are out of scope (these may not be what you want), as the charter does not rule these out, the use cases can go beyond what the WG has for its 1st set of deliverables as a broad set of use cases helps guide the WG forward.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Thursday, July 31, 2014 10:36 PM
To: [email-masked]
Subject: Re: [Ace] Use Case draft

My take is that the pairing of the thermostat with the AM is out of scope.
Once paired, the process by which the AM helps the thermostat talk to the furnace or AC or your Mike's Wife's Phone (Henceforth: MWP) is in scope.

    > contents of a foreclosed home, is way out of scope, though.)

On the day your house transfer closes, you arrange to disclose your keys (yes, your private house keys) to the new owner, probably via your lawyer.
Probably these are the keys used by the AM/AS to talk to the constrained
devices, not the ones on your phone.   The new owner uses either the existing
AM/AS (after a factory default), or a replacement AM/AS to rekey the entire network, same as you would change the tumblers on your house.

As for foreclosure, the banks will presumably want things escrowed to them, just as they insist that I have life insurance as a condition of my mortgage. (and will happily sell that to me if I'm stupid)

    > I don’t think UCAN discusses ownership transfer.

If there are certificates from manufacturer to owner as part of the network ownership claim that UCAN envisions, then ownership transfer amounts to adding another layer in a certificate chain.  There are various ways to do this, with different properties.
But, that relationship is about bootstrapping the C/AM pairing, and is out of scope for ACE.

    > detection is out of scope.

If there is a proximity sensor, then it might act as a sort of RS, AS or AM, which may provide an ACE format ticket that indicates the C is proximate, and presenting this ticket to another RS (the light), might be enough to control it.  The protocol by which the proximity sensor pairs with you (determines your proximity) is probably out of scope,  the result of the pairing should be in scope.

--
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 17:25:20 -0400

Rene Struik <[email-masked]> wrote:
    > may only involve a change to *public* configuration tables (what I
    > would term "role to device mappings"), at least if one uses public key
    > based techniques. These could simply be propagated over the
    > network. Not sure why one would need to introduce another employment
    > vehicle for lawyers, notaries, and legal departments and add cost where
    > almost zero-cost seems possible.

802.1AR provides for both replacing the private key or replacing just the
public certificate.

    > chains would encode the entire history of device ownership. In my mind,

That is one option: it permits everything to be done offline, and without
any of the original owners being involve, or having a veto.

A second option is for each owner to change the certificate after receiving
the device.

A third option is for the original vendor to re-issue a new certificate to
the new owner.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 17:28:37 -0400

Anthony Nadalin <[email-masked]> wrote:
    > I'm not sure why you are saying these are out of scope (these may not
    > be what you want), as the charter does not rule these out, the use
    > cases can go beyond what the WG has for its 1st set of deliverables as
    > a broad set of use cases helps guide the WG forward.

If it makes the use case more understandable, great.
Solving those problems is presently out of scope.
(Note: I'm actually really interested in solving these problems, but I think
we need to not get bogged down in the join problem until later)