Subject: [Iot-onboarding] Using Threshold techniques in onboarding.

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Nov 2020 19:44:20 -0500

I have running code and a spec for one way to skin this particular cat. The
draft is not quite ready but its close:
https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-15.html

Let's consider what we want to do when we onboard a device:

1) Establish initial communication with the device.

2) Configure the device to operate under control of the owner. Including
the ability to connect to the owner's network and authenticate commands
from the owner.

3) Establish a trust context that is verifiably independent of the
manufacturer and supply chain.

4) Reconfigure the device as necessary including the ability to switch wifi
networks, reset device config without needing to repeat onboarding, etc.
etc. without the need to climb a ladder at 3am in the morning because the
smoke alarm decided to throw away its configuration data on a whim.

Onboarding must become a one time operation. No excuses. Onboarding
configuration requires user effort which is precious. Configurations MUST
survive a hard reset of the device. The only time the configuration should
be forgotten is when the owner requires it.

TLS configuration was raised in SECDispatch. I believe DANE is the wrong
tool for the same reason CAs are the wrong tool: PKIX PKI is really not
designed for IoT. In particular, PKIX certificates are bound to DNS names
which requires that they expire within a short timeframe. Moving from the
WebPKI to DNSSEC doesn't help because DNS names are rented, not owned.

The expiry issue aside, enterprises and IETF participants have DNS domains
of their own. Consumers do not. And so binding to DNS names...

So one approach I have proposed in the past is to use Strong Internet
Names. These are simply a fingerprint of a public key that is mapped to a
reserved portion of DNS namespace.

So lets say that Alice's coffee-pot has a TLS key with the fingerprint
MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4. We can use that to establish a domain
name that allows us to authenticate the TLS cert without reference to any
external trust provider:

coffee.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4

That is not the sort of identifier I want to ever throw in a user's face.
But it is perfectly OK for an internal buried in the guts identifier. That
is what I started with four years ago... I have moved on a bit since.

In principle, we could just issue strong name certificates when a device is
manufactured. And that would be perfectly adequate for most user's actual
needs. Right up until some manufacturer is found to have kept track of all
the keys ever issued and has suffered a breach. This approach is not
acceptable for most enterprises and particularly not for HIPPA / SCI type
applications.

The solution is to take advantage of the fact that all Diffie Hellman Keys,
including Elliptic Curve keys support threshold key generation.

The device ships with an ECDH {public, private} keypair {x.P, x} When the
device is onboarded, the administrator issues a second set of keys {y.P, y}
and passes the private value y to the device by means of a secure channel
and a certificate for the key {z.P, z} where z=x+y.

Only the device has the means to calculate x+y. But the administrator can
calculate z.P because z.P = x.P + y.P.

Using this approach means that the user is completely insulated from any
malice or incompetence on the part of the manufacturer (or subsequent
supply chain compromise) provided only that the administration device
chooses a strong value of y. Contrawise, the user is protected if the
administrative device is faulty unless the device manufacturer defects.

Threshold is really, really powerful. You can have exactly as much fault
tolerance as you like, all you have to do is to introduce another party to
share the key with.

So what is the user experience like in practice? Well I have not yet fully
considered the enterprise case where we have to consider the distinction
between the owner and the user and consider insider threats. But I do have
three onboarding scenarios for the user case:

1) Witness value comparison (with optional PIN code)

If the device to be onboarded has a keyboard, Alice enters her Mesh
callsign ([email-masked]) on the device to be connected. The device
spits out a witness value which should appear on the administration device.
If the witness values match exactly, everything is correct and the
connection request can be accepted. Alternatively, an out of band PIN code
may be used as an authentication mechanism.

2) QR code presented on administration device.

If the device to be connected has either a camera or some means of
accepting a short range communication and a means of placing the device
into an onboarding mode, the Mesh callsign and PIC code can be presented in
this form allowing the device to connect without the need to enter data.

3) Static QR code printed on the connecting device.

The connection can also be made by means of a static QR code printed on the
device itself. This must provide some means of bootstrapping a local
communication channel between the devices to complete the connection
process and provision the initial network configuration.

One of the principles of the Mesh is autonomy. Users should be in control
of their digital environment. So what I am currently working on is a
mechanism to allow users to switch Mesh Service Providers without switching
costs.This will allow the mesh callsign to simply become @alice which will
be a lifelong name assigned to Alice that never needs to change unless she
wants to change it. She can switch her provider (e.g. moves from a Comcast
served area to Verizon) but she doesn't need to change her callsign. All
her existing devices will adjust automatically.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Nov 2020 07:20:44 +0100

Inline

> manufacturer and supply chain.

In ANIMA/BRSKI and friends we typically swap your 2) and 3), so that
3) itself can happen under the owner trust context and therefore minimizes
what happens with the device under "ownership" of manufacturer/seller.

> smoke alarm decided to throw away its configuration data on a whim.

In ANIMA/ACP we embed in devices minimal, automated & trusted connectivity
that is intended to be "undestroyable" by operator/SDN-controller mistakes.
(effectively an automaticac out-of-band management network).

> Onboarding must become a one time operation. No excuses.

Once per board ;-)

Aka: for most devices you probably do not need to repeat onboarding unless
ownership changes. Not sure yet what this means for cases such as leased equipment
in multi-tentn office environments (leased) for example.

> Onboarding configuration requires user effort which is precious.

Its primarily error prone even for remote automation, which is one aspect that
ANIMA/ACP attempts to eliminate.

> Configurations MUST survive a hard reset of the device.
> The only time the configuration should be forgotten is when the owner requires it.

Yes. Unfortunately, i have not seen a lot of IETF documentation about this
device level operational models. I had a hard time to push a bunch of ACP
related operational aspects in this space through IETF/IESG review because
they are "internal" to the node and not "protocol on the wire". 

But i think we should have a lot more of these aspects standardized. Even
though it will be hard to agree on models for it.

> designed for IoT.

I don't even know what IoT vs. non-IoT is. Problems such as different
levels of "reset" already apply for decades to routers. Even simple
operational aspects such as "boot once with new firmware, and automatically
reboot old firmware within 10 minutes unless remote operations has cancelled
this fallback-reboot" - have not been standardized as operational device
requirements. And have not really been implement well in many routers (haven't
looked recently..).

> In particular, PKIX certificates are bound to DNS names

Haha. Indeed. Are there actually cases where DNS names where forcefully
removed from owners ? Otherwise one could make the argument that any
buyer of DNS names should pay upfront for the following 30 years for the domain
name as soon as one discovers that the domain name is hardcoded into
equipment. I am sure RIR would love those upfront payments ;-)

> of their own. Consumers do not. And so binding to DNS names...

Yes. Way too little overall automation for DNS name allocation. And the
problem of long enough ownership...

> reserved portion of DNS namespace.

Hmm.. reminds me of all those informal web-pages where you could "register"
a ULA you picked. I actually had i think two of them mentioned in ACP draft
until they vanished on me.

Aka: there are hash collisions, so i would first have to wrap my head
around the potential of hash collision attacks. Need to not make the public
key/hash known to anyone non-trusted until its locked into DNS.

> is what I started with four years ago... I have moved on a bit since.

You probably want to come up with a DHT way to hierachically split up such
a space so that individual DNS servers would not be overloaded once this
domain grows globally.

> manufactured.

That is is a broad expectation. Would be nice.. Not sure if its feasible for
all IoT devices. Even for IT equipment, the process of staging certs
in a trusted way into TPM or the like is quite advanced.

> And that would be perfectly adequate for most user's actual
> the keys ever issued and has suffered a breach.

Right. Main issue in manufacturing is the time it would take low-end device
'TPM' hardware to calculate a key pair, so the manufacutring process is
highly security critical.

> This approach is not

No idea about these type of apps. You mind to prive (pointers to) some insight ?

> calculate z.P because z.P = x.P + y.P.

Nice option. 

Does of course expect that x was never leaked from the manufacturer.

Not sure too if during deployment the time taken to locally calculate a
standalone {z.P, z} would be too significant. Couple minutes..

In ANIMA we developed the concept of vouchers (rfc8366), which authenticates
the owner to the device by mean of a manufacturer signed object (the voucher)
(device trusts manufacturer signed object).

We could have an extended voucher object which includes encrypt(x.P, y).
This could replace the secure channelt to the device to enroll the new
keypair.

> chooses a strong value of y.

And that the manufacturer has no backdoors. Which obviously politicians
are claiming these days for every device from another political empire.
And then the same politicians will go back and force their own political
realm backdoor into their realm equipment.

*sigh*

I guess for low-end-enough IoT devices one could still verify open source
chip designs and verify samples of chips under actual electroni microscopes
to validate the chip manufacturer.

> Contrawise, the user is protected if the

Didn't parse that.

> may be used as an authentication mechanism.

Not quite complete dscription i think. Whats the condition for alice's
ownership ? Just physcial posession ? If not, then what ?

> this form allowing the device to connect without the need to enter data.

bearer token on QR. 

> process and provision the initial network configuration.

Yeah. physical posession. All type of problems with those on-box
ownership authenticators depending on distribution channels.

> her existing devices will adjust automatically.

Good luck

Cheers
    Toerless

> -- 
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Nov 2020 17:09:45 -0500

On Tue, Nov 17, 2020 at 1:20 AM Toerless Eckert <[email-masked]> wrote:

> what happens with the device under "ownership" of manufacturer/seller
>

In the Mesh, these happen simultaneously... I was not really thinking of
this as an ordered sequence though.

> I don't even know what IoT vs. non-IoT is.

IoT is really a set of constraints and limitations that were not
encountered in the workstation era of computing that the Internet emerged
out of. IoT means not being able to count on the device having a keyboard
or a display. It means possibly having limited performance. It often means
having multiple users but not having accounts.

> removed from owners ?

Yes, UDRP.

And I am going to have to think of similar for Mesh callsigns
since @cocacola can only be used by one party...

> Otherwise one could make the argument that any

I have an alternative architecture that makes use of an notarized append
only log to issue permanent names for $0.10. The user only needs one of
those for a lifetime and only needs to interact with the registry when
changing their service provider. The registry does not support queries,
that is the job of service providers which simply take a complete copy of
the registry.

> key/hash known to anyone non-trusted until its locked into DNS.

I use UDFs as the fingerprint format. That allows the work factor to be set
to any degree of difficulty desired. For most purposes, a work factor of
2^128 is sufficiently prohibitive. UDFs are always calculated using
SHA-2-512 or SHA-3-512 but can be expressed at variable precision. So I can
specify 120 bits (30 chars) to save space or give 260 bits (52 chars) if I
want to have quantum cryptanalysis resistant work factor.

> a space so that individual DNS servers would not be overloaded once this

I looked into that at one point. But I found a way to design around the
need to go there. It not really necessary as these domains don't require
DNSSEC, they are roots of authority in their own right. So its just a query
function and a resolver can only respond for the domains it knows about. So
if we used SINs, the local DNS resolver might know a few hundred of them at
most.

> highly security critical.

Key generation is pretty quick for ECDH, its the same as a key use. But
from the security point of view, there is really no difference between keys
generated on the device and keys installed during manufacture that is
visible to the end user. So they can't trust the key that much regardless.

> Does of course expect that x was never leaked from the manufacturer.

Actually not. If x is leaked during manufacture, the key is still as secure
as the value y. That is the whole beauty of this approach. The
manufacturer can mess up completely and the only damage is a very small
window of vulnerability during the device connection operation.

> standalone {z.P, z} would be too significant. Couple minutes..

Same as any other Ed448 or X448 operation - a few ms.

> This could replace the secure channelt to the device to enroll the new

That sounds like a way forward. I am happy to align with Anima nomenclature
if it helps.

> realm backdoor into their realm equipment.

There are different types of backdoor. What my technology does is to allow
the manufacturer to prove that they do not have a backdoor to the keys
users make use of in applications as a result of information available at
the time of manufacture.

What I cannot do is to provide a complete set of controls that prevent a
manufacturer leaking information through a side channel after the device is
provisioned. You can apply threshold as many times as you like so that the
number of parties that have to collude is as large as you like but no
protocol can ever be secure if EVERY trusted party defects.

> > administrative device is faulty unless the device manufacturer defects.

Alice is generating y on her administration device. What if the
administration tool has a backdoor and sends a copy of y to Mallet? Well
Alice is still protected provided that the device manufacturer is honest.
It takes disclosure of x AND disclosure of y for there to be a breach.

> > So what is the user experience like in practice?

Zero effort security.

The only user experience that is acceptable to me is no user experience at
all. Once devices are connected, they just work and Alice is not even aware
of the fact she is using end to end encryption. The drafts describe this in
more detail. But basically, Mesh email works just like regular email. Mesh
messaging works just like regular chat, etc. etc.

The only time the user experience changes at all is during the
connection/onboarding process and that is simply the scanning of a QR code
or the exchange of an IR, Bluetooth or other affordance and saying 'yes I
want to connect this device and here is what I want to allow it to do'. If
the coffee pot wants access to the passwords catalog... its a bad coffee
pot.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 18 Nov 2020 09:33:12 +0100

Phil:

Let me open a new thread on that sub-topic and add ANIMA WG:

I vry much like your ECDH idea and i think one way to proliferate it,
would be to specify in an RFC an "enrolling voucher". I'd be happy
to help co-author that, but if i look at all the other voucher RFC/drafts
we have, there is a lot of knucklehead encoding work i am not the expert
on - so maybe other would like to jump in.

To restarte for ANIMA your idea/mechanism:

 device ships with an ECDH {public, private} keypair {x.P, x}
 When device is onboarded/owned, the owner issues a second set of keys
 {y.P,y} and passes the private value y to the device by means of a secure channel
 and a certificate for the key {z.P, z} where z=x+y.

An enrolling voucher would have to have:

 a) The required subset of the existing voucher components:
 identifier of device (such as x.P), and voucher signed by some TA
 that the device trusts before onboarding.

 b) New Stuff:
 b.1) y encrypted with some fitting ECDH derived scheme with x.P, so that
      only the device itself can decrypt y.
 b.2) (optional) A certificate for z.P signed by whatever TA the owner has selected
      (not needed when the node itself does not need to run protocols
       relying on certs, but maybe only needs the z key pair) (*1)

The cool novelty of this scheme is that we eliminate the need for a lot of
communications otherwise needed, so these vouchers would make all those
"disconnected" use-cases easier. Normally the device would need to have
an active secure connection to enroll a certificate or to indicate a new
key-pair it locally creates. In this mechanism, the voucher could be, quite
similar to ACME cert renewal certificates (without re-keying!) distributed
across public caches and downloaded through arbitrary chain of sneakernet
(USB-stick-net).

(*1) There is an interesting limitation/change of the scheme in so far as that
usually a CA may want to have some form of "proof of ownership" of in this
case z before it would sign a certificate for z.P. Because the device is
decidedly not involved here, the CA would need to be willing to sign 
the cert without such proof of posession. This might require according
extensions to the certificate that would indicate this new type of certificate.
Obvioulsly, when we use non-public TA, such as typically assumed in ANIMA/ACP,
this is not an issue at all.

So, would be interesting to hear what others think.

Cheers
    Toerless

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 18 Nov 2020 09:35:20 +0000

Hi Toerless,

It's an interesting topic, I'd like to join in and contribute.
I think the use of such ECDH methodology is to get rid of certificates or PKI mechanism. And if that works, it will benefit the IoT devices very much.
By the way, I think we may also need to have a "lightweighted BRSKI" draft to accommodate the use of "enrolling voucher". For example, by using this "enrolling voucher", the certificate enrollment part of using EST in BRSKI can be omitted. Also, BRSKI replies on the devices shipping with an IDevID/IDevID certificate, if we consider to completely throwing away certificates and ship the device with an key pair, then we also need to address this change .

Regards & Thanks!
Wei Pan

-----Original Message-----
From: Iot-onboarding [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: Wednesday, November 18, 2020 4:33 PM
To: Phillip Hallam-Baker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [Iot-onboarding] Phil*: "self-enrolling voucher" - (was: Re: Using Threshold techniques in onboarding.)

Phil:

I vry much like your ECDH idea and i think one way to proliferate it, would be to specify in an RFC an "enrolling voucher". I'd be happy to help co-author that, but if i look at all the other voucher RFC/drafts we have, there is a lot of knucklehead encoding work i am not the expert on - so maybe other would like to jump in.

 device ships with an ECDH {public, private} keypair {x.P, x}  When device is onboarded/owned, the owner issues a second set of keys  {y.P,y} and passes the private value y to the device by means of a secure channel  and a certificate for the key {z.P, z} where z=x+y.

 Only the device has the means to calculate x+y. But the administrator can  calculate z.P because z.P = x.P + y.P.

 a) The required subset of the existing voucher components:
 identifier of device (such as x.P), and voucher signed by some TA  that the device trusts before onboarding.

 b) New Stuff:

The cool novelty of this scheme is that we eliminate the need for a lot of communications otherwise needed, so these vouchers would make all those "disconnected" use-cases easier. Normally the device would need to have an active secure connection to enroll a certificate or to indicate a new key-pair it locally creates. In this mechanism, the voucher could be, quite similar to ACME cert renewal certificates (without re-keying!) distributed across public caches and downloaded through arbitrary chain of sneakernet (USB-stick-net).

(*1) There is an interesting limitation/change of the scheme in so far as that usually a CA may want to have some form of "proof of ownership" of in this case z before it would sign a certificate for z.P. Because the device is decidedly not involved here, the CA would need to be willing to sign the cert without such proof of posession. This might require according extensions to the certificate that would indicate this new type of certificate.
Obvioulsly, when we use non-public TA, such as typically assumed in ANIMA/ACP, this is not an issue at all.

Cheers
    Toerless

On Tue, Nov 17, 2020 at 05:09:45PM -0500, Phillip Hallam-Baker wrote:
> > > 2) Configure the device to operate under control of the owner. 
> > > Including the ability to connect to the owner's network and 
> > > authenticate commands from the owner.
> > >
> > 3) itself can happen under the owner trust context and therefore 
> > minimizes what happens with the device under "ownership" of 
> > manufacturer/seller
> >
> 
> In the Mesh, these happen simultaneously... I was not really thinking 
> of this as an ordered sequence though.
> 
> > > tool for the same reason CAs are the wrong tool: PKIX PKI is 
> > > really not designed for IoT.
> >
> encountered in the workstation era of computing that the Internet 
> emerged out of. IoT means not being able to count on the device having 
> a keyboard or a display. It means possibly having limited performance. 
> It often means having multiple users but not having accounts.
> 
> > > which requires that they expire within a short timeframe. Moving 
> > > from the WebPKI to DNSSEC doesn't help because DNS names are rented, not owned.
> >
> > Haha. Indeed. Are there actually cases where DNS names where 
> > forcefully removed from owners ?
> 
> 
> Yes, UDRP.
> 
> And I am going to have to think of similar for Mesh callsigns since 
> @cocacola can only be used by one party...
> 
> 
> 
> > Otherwise one could make the argument that any buyer of DNS names 
> > should pay upfront for the following 30 years for the domain name as 
> > soon as one discovers that the domain name is hardcoded into 
> I have an alternative architecture that makes use of an notarized 
> append only log to issue permanent names for $0.10. The user only 
> needs one of those for a lifetime and only needs to interact with the 
> registry when changing their service provider. The registry does not 
> support queries, that is the job of service providers which simply 
> take a complete copy of the registry.
> 
> > around the potential of hash collision attacks. Need to not make the 
> > public key/hash known to anyone non-trusted until its locked into DNS.
> >
> 
> I use UDFs as the fingerprint format. That allows the work factor to 
> be set to any degree of difficulty desired. For most purposes, a work 
> factor of
> SHA-2-512 or SHA-3-512 but can be expressed at variable precision. So 
> I can specify 120 bits (30 chars) to save space or give 260 bits (52 
> chars) if I want to have quantum cryptanalysis resistant work factor.
> 
> 
> > > So lets say that Alice's coffee-pot has a TLS key with the 
> > > fingerprint MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4. We can use that to 
> > > establish a domain name that allows us to authenticate the TLS 
> > > cert without reference to any external trust provider:
> > >
> > You probably want to come up with a DHT way to hierachically split 
> > up such a space so that individual DNS servers would not be 
> > overloaded once this domain grows globally.
> >
> 
> I looked into that at one point. But I found a way to design around 
> the need to go there. It not really necessary as these domains don't 
> require DNSSEC, they are roots of authority in their own right. So its 
> just a query function and a resolver can only respond for the domains 
> it knows about. So if we used SINs, the local DNS resolver might know 
> a few hundred of them at most.
> 
> > > needs. Right up until some manufacturer is found to have kept 
> > > track of
> > all
> > Right. Main issue in manufacturing is the time it would take low-end 
> > device 'TPM' hardware to calculate a key pair, so the manufacutring 
> > process is highly security critical.
> >
> 
> Key generation is pretty quick for ECDH, its the same as a key use. 
> But from the security point of view, there is really no difference 
> between keys generated on the device and keys installed during 
> manufacture that is visible to the end user. So they can't trust the key that much regardless.
> 
> 
> > > The solution is to take advantage of the fact that all Diffie 
> > > Hellman
> > Keys,
> > > The device ships with an ECDH {public, private} keypair {x.P, x} 
> > > When the device is onboarded, the administrator issues a second 
> > > set of keys {y.P,
> > y}
> > > and passes the private value y to the device by means of a secure 
> > > channel and a certificate for the key {z.P, z} where z=x+y.
> > >
> > > Only the device has the means to calculate x+y. But the 
> > > administrator can calculate z.P because z.P = x.P + y.P.
> >
> > Nice option.
> >
> Actually not. If x is leaked during manufacture, the key is still as 
> secure as the value y. That is the whole beauty of this approach. The 
> manufacturer can mess up completely and the only damage is a very 
> small window of vulnerability during the device connection operation.
> 
> > In ANIMA we developed the concept of vouchers (rfc8366), which 
> > authenticates the owner to the device by mean of a manufacturer 
> > signed object (the
> > voucher)
> > This could replace the secure channelt to the device to enroll the 
> > new keypair.
> >
> 
> That sounds like a way forward. I am happy to align with Anima 
> nomenclature if it helps.
> 
> 
> 
> > > Using this approach means that the user is completely insulated 
> > > from any malice or incompetence on the part of the manufacturer 
> > > (or subsequent supply chain compromise) provided only that the 
> > > administration device chooses a strong value of y.
> >
> > And that the manufacturer has no backdoors. Which obviously 
> > politicians are claiming these days for every device from another political empire.
> > And then the same politicians will go back and force their own 
> > political realm backdoor into their realm equipment.
> >
> 
> There are different types of backdoor. What my technology does is to 
> allow the manufacturer to prove that they do not have a backdoor to 
> the keys users make use of in applications as a result of information 
> available at the time of manufacture.
> 
> What I cannot do is to provide a complete set of controls that prevent 
> a manufacturer leaking information through a side channel after the 
> device is provisioned. You can apply threshold as many times as you 
> like so that the number of parties that have to collude is as large as 
> you like but no protocol can ever be secure if EVERY trusted party defects.
> 
> > chip designs and verify samples of chips under actual electroni 
> > microscopes to validate the chip manufacturer.
> >
> > > Contrawise, the user is protected if the administrative device is 
> > > faulty unless the device manufacturer defects.
> >
> > Didn't parse that.
> >
> 
> administration tool has a backdoor and sends a copy of y to Mallet? 
> Well Alice is still protected provided that the device manufacturer is honest.
> > > Threshold is really, really powerful. You can have exactly as much 
> > > fault tolerance as you like, all you have to do is to introduce 
> > > another party
> > to
> > > share the key with.
> > >
> The only user experience that is acceptable to me is no user 
> experience at all. Once devices are connected, they just work and 
> Alice is not even aware of the fact she is using end to end 
> encryption. The drafts describe this in more detail. But basically, 
> Mesh email works just like regular email. Mesh messaging works just like regular chat, etc. etc.
> 
> connection/onboarding process and that is simply the scanning of a QR 
> code or the exchange of an IR, Bluetooth or other affordance and 
> saying 'yes I want to connect this device and here is what I want to 
> allow it to do'. If the coffee pot wants access to the passwords 
> catalog... its a bad coffee pot.